HotJava(tm): The Security Story

WHAT · what your browser told me about you when you weren't looking

class vector {
    int arr[];
    int sum() {
        int la[] = arr;
        int S = 0;
        for (int i=la.length; --i>=0;)
            S += la[i];
        return S;
    }
}

	iload_1	Load integer variable, stack type state=I
	iconst 5	Load integer constant, stack type state=II
	iadd	Add two integers producing an integer, stack type state=I

The

    what your browser told me about you when you weren't looking

echo CGI at UIUC mentioned on cypherpunks (http://www.hks.net/cpunks/
cpunks-9/0095.html) in Nov. 1994 seems to be down for the count (it was
http://www.uiuc.edu/cgi-bin/printenv )).  It would provide you with a page
showing the information your browser had given to the server in the HTTP
Request-Header.

However, others exist to take up the slack. Here's a directory I compiled
today (thanks to WWWW, Lycos, etc.) of current, working HTTP
Request-Header and resulting server environment variable echoes. I'm sure
I've missed some, if not many. Follow up with additions, if you want.
Better yet, add these and the additions to your favorite privacy and
security pages.

HTTP Request-Header Echoes

Machine Information at MIT (http://www.mit.edu:8001/machine)
    Feeds back your machine name, IP address, and finger info.  Not really
    a request-header echo at all, but useful.

Echo at TU-Berlin (http://www.cs.tu-berlin.de/sui/eserte/cgi-rcs/home/
eserte/.public_html/index.html
    Raw text echo of your HTTP request-header info.

Echo by Pierre Omidyar at best.com (http://www.best.com/~pierre/printenv.
cgi) and at ebay.com (http://www.ebay.com/printenv.cgi)
    Two paths for reaching the same CGI script. Produces nicely formatted
    HTML output showing your HTTP request-header info. Simple perl source
    for the script is available from Pierre's Web Tips (http://www.best.
    com/~pierre/web-authoring.html) page.

Echo by mjd at cis.upenn.edu (http://www.cis.upenn.edu/cgi-bin/mjd/
printenv)
    Produces formatted HTML echo of your HTTP request-header info.

Echo at hyperreal.com (http://www.hyperreal.com/cgi-bin/printenv)
    Produces plaintext HTML echo of your HTTP request-header info.

Echo at Whithead Institute--MIT (http://www-genome.wi.mit.edu/WWW/
examples/Ch9/printenv.pl
    Produces formatted HTML echo of your HTTP request-header info. Simple
    perl source for this script is available in the Chapter 9 script
    examples (http://www-genome.wi.mit.edu/WWW/examples/Ch9/) from
    Lincoln Stein (http://www-genome.wi.mit.edu/~lstein/)'s book, How to
    Set Up And Maintain a World Wide Web Site (http://www-genome.wi.mit.
    edu/WWW/).

Echo by cloos at io.com (http://www.io.com/cgi-user/cloos/environment)
    Raw text echo of your HTTP request-header info. Also provides a whole
    bunch more, including the script's runtime environment.

And now, again in the original HTML:

> 

From nobody at REPLAY.COM  Fri Oct 27 10:23:45 1995
From: nobody at REPLAY.COM (Anonymous)
Date: Sat, 28 Oct 1995 01:23:45 +0800
Subject: TWP Ups Net Freedom
Message-ID: <199510271518.QAA21481@utopia.hacktic.nl>

The Washington Post, October 27, 1995

Freedom of Net Speech (Editorial)

Is speech on the Internet like speech in a public square,
or is it more like speech in a privately owned mall,
where leafleters and demonstrators need permission? And
what about universities, where students using university
accounts for e-mail and other messages may find
themselves subjected to disciplinary rules? The latter
problem occurred most recently at Virginia Tech, which
has come under challenge for disciplining a student who
sent a letter described as abusive to another student.

The difficulty of framing such questions or even of
defining the terms they're made up of (Is cyberspace
really a "space," or just the ability of a lot of
machines to talk to one another?) should be ample
illustration of why millions of Internet users are still
sloshing around in a state of legal ambiguity. And that
ambiguity, though congenial to the anarchically inclined
folks who have been in cyberspace since its
not-very-remote beginnings, can't be sustained much
longer as millions of users pile into cyberspace through
commercial, university-owned and workplace hookups. The
providers of these hookups all have an interest in what
their users "say" to other users once they're on line,
but the interests vary. Some providers are afraid -- with
cause -- that they may be liable for pirated, libelous or
other lawbreaking material posted on their accounts, or
(depending on the outcome of assorted legislation) for
transmitting pornographic or indecent material to minors.
Universities have another set of motivations that go
beyond fear of legal vulnerability and that have led many
-- including Virginia Tech -- to institute student
conduct policies that can be used to curb even
non-cyberspace speech.

Virginia Tech authorities say the existing student life
policy prohibits "words or acts" that constitute "abusive
conduct" that "demeans, intimidates, threatens or
otherwise interferes with another person's rightful
actions or comfort," whether on line or off. As with the
notorious "hate speech" regulations at many campuses,
this is a dangerously broad category, though the lines
between interfering with someone's comfort and actually
threatening him are probably drawable by a court.

Technologically oriented civil liberties groups such as
the Electronic Frontier Foundation have been arguing for
some time that if First Amendment rights in cyberspace
aren't codified and nailed down early, tendencies toward
restraint will multiply to cover more and more of the new
"sectors," and this will greatly reduce the potential of
electronic communication both socially and commercially.
An even more cold-eyed pragmatic argument is that speech
restrictions, notoriously hard to enforce in the real
world, are even more so in the virtual one: In one
formulation much repeated by programmers, the Internet
"interprets censorship as a malfunction and detours
around it." Add this to the practical impossibility of
commercial owners monitoring every message sent via
cyberspace, and you have enforcement nightmares. There
are better and broader arguments, though, for being
skeptical of any efforts to restrict the content of
cyberspace speech in ways that go beyond existing and
permitted controls on real-world speech, whether on child
pornography, stalking, libel or the rest.

Universities have some wiggle room here, but for the same
reason university "hate speech" codes or restrictions on
what professors may say in class are a terrible idea,
it's bad practice to restrict student speech on-line.
Free speech is good for the Internet for the same reasons
it's good for the real world.

-----

From asgaard at sos.sll.se  Fri Oct 27 10:26:09 1995
From: asgaard at sos.sll.se (Mats Bergstrom)
Date: Sat, 28 Oct 1995 01:26:09 +0800
Subject: FTP export walls
In-Reply-To: <199510271446.KAA13555@jekyll.piermont.com>
Message-ID: 

>Perry E. Metzger wrote:

>> Michael Froomkin writes:

> > If anyone from MIT is reading this, it would be a real public service to 
> > put on a web site (a) what the system used for the release of PGP is 
> > exactly and (b) what assurances (oral, written, names & dates) was 
> > received from State/Commerce that this was legal.

> I don't think they got any sort of approval from State or Commerce --
> I think they just discussed it with their own lawyers.

Last July *hobbit* (hobbit at avian.org) presented to this list a
description of "The FTP Bounce Attack" and stated that it's trivial to
hack past a defense like this (well, it didn't seem trivial to me, but
I'm not a unix wizard). Obviously, there is no real need for such attacks
with PGP and 'everything' else available at non-US sites, and I guess it
would leave traces? But it would be interesting to know if anybody have
successfully tried it at MIT or some other export-restricted FTP site.

Mats

From tcmay at got.net  Fri Oct 27 10:27:54 1995
From: tcmay at got.net (Timothy C. May)
Date: Sat, 28 Oct 1995 01:27:54 +0800
Subject: e-mail, business and privicy
Message-ID: 

At 3:15 PM 10/27/95, WOOD at VAX2.ROCKHURST.EDU wrote:
>An old subject, but could someone please give me a pointer
>to the legalities of reading other peoples mail in the working
>environment.
>
>Many thanks,

I doubt many others will offer answers to this one, so I will.

The usual way to get authorization to read the mail of other people is to
be officially deputized as a member of the Citizen's Morality Watch. Your
local law enforcement office, or the FBI, can help you fill out the
paperwork and get you the badge and ID card. (I signed up early, and have
one of the ID cards signed by William Webster.)

Once deputized, you are authorized to read whatever mail you may think a
threat to the public consciousness.

And when GAK arrives, you'll be duly authorized to gain access to escrowed
keys. And to escrowed house keys, escrowed car keys, and escrowed diaries.

This will finally give us the same measure of security that the Soviets had
when babushkas and KGB men read one's mail, and that the Iranians now have
with the Islamic Purity Patrols on the streets of Teheran.

--Klaus! von Future Prime, avatar

From enzo at ima.com  Sat Oct 28 01:30:49 1995
From: enzo at ima.com (Enzo Michelangeli)
Date: Sat, 28 Oct 95 01:30:49 PDT
Subject: Mark Twain Bank's DigiCash offer
In-Reply-To: <9510271546.AA00580@ch1d157nwk>
Message-ID: 

On Fri, 27 Oct 1995, Andrew Loewenstern wrote:

> The gotcha being that as long as your money is in the "mint" it is not under  
> FDIC protection...  Just how safe your cash is when it is in the mint is  
> entirely related to the security of Mark Twain's systems, which are  
> high-profile machines that will surely be subjected to many cracking  
> attempts.  Some may prefer to keep complete control over their cash and store  
> all of it themselves.  Unlike physical cash, this stuff can be split up,  
> encrypted, and stored in multiple places, possibly offering more security  
> than the Mark Twain "mint."

Unfortunately, it also expires (btw, how soon??):

----- 8< ----- quoted from http://www.marktwain.com/digifaq.html ---------
Once the money is on your hard drive, you can hold it (until expiration 
date - check this often), or spend it. 
--------------------------------------------------------------------------

Enzo

From mark at unicorn.com  Fri Oct 27 10:41:34 1995
From: mark at unicorn.com (Rev. Mark Grant)
Date: Sat, 28 Oct 1995 01:41:34 +0800
Subject: Diffie-Hellman Key Generation
Message-ID: 

Does anyone know of software available outside the US for generating 
large (1024-bit or more) Diffie-Hellman keys ? The default key for CTCP 
is only 512 bits, and I'd like to be able to give out some larger keys 
(e.g. 1024 and 2048 bits) so that people have a choice of the level of 
security that they want to use.

Alternatively, does anyone have any pre-generated large keys that I can 
put in there ?

Finally, I'm basing this on comments in 'Applied Cryptography' that D-H
keys should be at least 512 bits and preferably 1024. How does the
difficulty of breaking a D-H exchange with a 512 bit key compare to
breaking a 512 bit RSA key ? 

	Mark

From andrew_loewenstern at il.us.swissbank.com  Fri Oct 27 10:55:29 1995
From: andrew_loewenstern at il.us.swissbank.com (Andrew Loewenstern)
Date: Sat, 28 Oct 1995 01:55:29 +0800
Subject: Mark Twain Bank's DigiCash offer
Message-ID: <9510271546.AA00580@ch1d157nwk>

Hal writes:
>  As far as I can tell there is no charge for moving funds between
>  your ecash wallet and the "mint" at the bank.  The charges are for
>  moving between the "mint" and the world access account.  If you
>  had a shop which was able to pay much of its expenditures in ecash
>  it sounds like there would be no percentage fee to the bank.

The gotcha being that as long as your money is in the "mint" it is not under  
FDIC protection...  Just how safe your cash is when it is in the mint is  
entirely related to the security of Mark Twain's systems, which are  
high-profile machines that will surely be subjected to many cracking  
attempts.  Some may prefer to keep complete control over their cash and store  
all of it themselves.  Unlike physical cash, this stuff can be split up,  
encrypted, and stored in multiple places, possibly offering more security  
than the Mark Twain "mint."

andrew

From shamrock at netcom.com  Fri Oct 27 10:59:29 1995
From: shamrock at netcom.com (Lucky Green)
Date: Sat, 28 Oct 1995 01:59:29 +0800
Subject: How can e-cash, even on-line cleared, protect payee identity?
Message-ID: <199510271647.MAA07174@book.hks.net>

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

In article <199510260424.OAA12383 at sweeney.cs.monash.edu.au>,
jirib at sweeney.cs.monash.edu.au (Jiri Baum) wrote:

> What you'd really want is for Alice to pay for the new coins in ecash.

Right.

> I'm wondering whether a "coin-changer" would be easier or harder to
> set up than a "bank" (from regulatory point of view).

I don't think it would be any easier to set up. Harder perhaps, since its
sole purpose is money laundring. However, if there are several Ecash
currencies there is a legitimate need for Ecash currency arbitration. Who
is to stop the following protocol?

US Ecash -> Swedish Ecash
Swedish Ecash -> US Ecash

The resulting coins are no longer traceable unless the repayer cooperates.
The repayer (or in this case currency arbitrator) keeps of course a
percentage at each transaction. No different than a Casa de Cambio. It can
be set up anywhere and even be done anonymously. I am working on an
implementation.
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

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

iQBFAwUBMJENOCoZzwIn1bdtAQETtQGA1c2lAxu2HcrudvQ7OgIrJptiDBueqVM5
uYIuB4n0fNzv6kdh+LYqctKj2BzOlE22
=a7mC
-----END PGP SIGNATURE-----

From mark at unicorn.com  Fri Oct 27 11:08:35 1995
From: mark at unicorn.com (Rev. Mark Grant)
Date: Sat, 28 Oct 1995 02:08:35 +0800
Subject: Linux security issues
Message-ID: 

On Thu, 26 Oct 1995, Bill Frantz wrote:

> However, the pass phrase is not the only dangerous information. 
> Intermediate forms used for decrypting the RSA private keys, and the
> decrypted RSA private keys also have to be protected.  The logic of PGP
> requires that it keep at least one of these around for a long time, so it
> will probably be written to swap space.

Couldn't you use mmap() to map a disk file into your address space, keep 
all your secret data in that part of the address space, and then 
carefully wipe that file before exiting ?

I guess you'd then have the problem that people could just read that file
(if they had the priviledges to do so) to find all the secret data rather
than having to trawl through the swap file though.. and you'd still have
to worry about disk buffering. So it probably wouldn't be a big
improvement. 

	Mark

From warlord at MIT.EDU  Fri Oct 27 11:13:31 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Sat, 28 Oct 1995 02:13:31 +0800
Subject: Linux security issues
In-Reply-To: <199510270552.WAA17904@netcom7.netcom.com>
Message-ID: <199510271704.NAA07834@toxicwaste.media.mit.edu>

> Actually keeping the pass phrase out of swap space is fairly easy (although
> I havn't looked at the PGP code to see if it actually does this).  Read the
> pass phrase in raw mode, one character at a time and convert it one
> character at a time to the decryption key for the private RSA key.  Then
> the OS doesn't need to buffer the whole line, either in kernel space or in
> user space.

This isn't as easy as you think, and it completely breaks many
abstractions to do this!  PGP does some of this, but not all of it.
It does get the pasphrase one character at a time, however it does
buffer it all before hashing it to a key.  One reason is that you do
not necessarily know how big a session key you need, so you may need
to use different hashing techniques to get different sized keys.

It would be nice if PGP tried to lock its memory pages on OS's that
support page locking, so that some pages dont get swapped out.  But
that isn't a very general solution, since not all OS variants provide
such a mechanism.

-derek

From liberty at gate.net  Fri Oct 27 11:19:05 1995
From: liberty at gate.net (Jim Ray)
Date: Sat, 28 Oct 1995 02:19:05 +0800
Subject: PRZ On Mitchells
Message-ID: <199510271718.NAA56324@tequesta.gate.net>

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

Hello again cypherpunks:

[I hope this info. isn't already posted, my sincere apologies if it
has. I get the "digest" version of the firehose these days, and
there's a slight delay on my end.] Anyway, 

I'm informed by my brother in Punta Gorda, FL that "Mitchells in the
Morning" -- a conservative/libertarian husband & wife talkshow on
"National Empowerment Television," featured Phil Zimmermann and
Robert Holliman(sp?) President of the "Business Software Alliance"
this morning. Talk was mostly about how stupid software export
controls are, as PRZ was understandably reluctant to discuss details
of the grand jury investigation.

Humorous sidenote: PRZ said that the Exon  bill is the
equivalent of turning the entire Internet into the children's room
at the public library. I will be getting a videotape of the show in
about 2 weeks, and if anyone wants me to make them a copy please
e-mail me (privately!) and I will try to oblige.
JMR

Disemboondogglin' -- Reducing the rate of increase in a government
program when adjusted for inflation (as opposed to a "cut"). --
Tom Ray, my brother.

Visit my "Pretty Good Homepage" at http://shopmiami.com/prs/jimray/
Featuring cypherpunk stuff and some babypictures!
-----------------------------------------------------------------------
PGP key Fingerprint  51 5D A2 C3 92 2C 56 BE  53 2D 9C A1 B3 50 C9 C8 
Key id. #  E9BD6D35 (key on page & servers)  IANAL
-----------------------------------------------------------------------
Help Phil! email zldf at clark.net or http://www.netresponse.com/zldf
_______________________________________________________________________

From warlord at MIT.EDU  Fri Oct 27 11:19:53 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Sat, 28 Oct 1995 02:19:53 +0800
Subject: CJR returned to sender
In-Reply-To: 
Message-ID: <199510271718.NAA07989@toxicwaste.media.mit.edu>

> If anyone from MIT is reading this, it would be a real public service to 
> put on a web site (a) what the system used for the release of PGP is 
> exactly and (b) what assurances (oral, written, names & dates) was 
> received from State/Commerce that this was legal.

I can explain (and have explained in this forum) the technical aspect
of how the MIT PGP site works.  I was not involved in the law aspect
of the debate, so I cannot answer legal questions.

There is a two-tiered protection scheme.  The first scheme is that you
need to know the secret directory where PGP resides.  This directory
changes location every 30 minutes, so any attacker has a 30 minute
window in which a name will be valid.  Not 30 minutes from the time
they receive it, 30 minutes from the time the directory last changed
names.

The second scheme involves using reverse DNS lookups and comparing the
DNS hostname to a list of know US-valid hostnames/domains.

An attacker needs to be able to circumvent both schemes at once in
order to get to PGP.

I can go into more detail if people want, or I can take this offline
if people prefer.

-derek

From turner at TeleCheck.com  Fri Oct 27 11:45:50 1995
From: turner at TeleCheck.com (Joe Turner)
Date: Sat, 28 Oct 1995 02:45:50 +0800
Subject: e-mail, business and privicy
In-Reply-To: <01HWXJ7WNGYA000F24@VAX2.ROCKHURST.EDU>
Message-ID: <9510271741.AA04695@mercury.telecheck.com>

> 
> An old subject, but could someone please give me a pointer 
> to the legalities of reading other peoples mail in the working 
> environment.
> 
> Many thanks,	
> 

Unless otherwise notified, I believe you have a right to 
privacy.  Some companies are up front and make you sign a
piece of paper to the effect that when your at work... 

Here at TeleCheck, we had to sign a piece of paper that promised
that we wouldn't read each *other's* mail, after a nasty incident
in which involved an employee and forged mail ardently confessing
is new found homosexuality (boy was be suprised...).  But that
was a long time ago, which predates the notices we had to sign.

The point was clear.  Don't read your supervisor's mail or you will be
terminated (as an employee was). 

-- 
Joe N. Turner		Telecheck International
turner at telecheck.com    5251 Westheimer, PO BOX 4659, Houston, TX 77210-4659
			(800) 888-4922  *   (713) 439-6597

From hfarkas at carfax.ims.advantis.com  Fri Oct 27 11:52:51 1995
From: hfarkas at carfax.ims.advantis.com (Henry W. Farkas)
Date: Sat, 28 Oct 1995 02:52:51 +0800
Subject: e-mail, business and privicy
In-Reply-To: <01HWXJ7WNGYA000F24@VAX2.ROCKHURST.EDU>
Message-ID: 

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

On Fri, 27 Oct 1995 WOOD at VAX2.ROCKHURST.EDU wrote:

> An old subject, but could someone please give me a pointer 
> to the legalities of reading other peoples mail in the working 
> environment.

There is a new O'Reilly book out called _Computer Crime_ that covers the
entire arena in more detail than you'll be likely to ever need.  I hope.

It's decidedly oriented towards the law enforcement community, not
"Computer Folk". Though the title focuses on crime, you'll find what 
you need here. 

===========================================================================
     Henry W. Farkas      |     Me?     Speak for IBM?     Fat chance.
 hfarkas at ims.advantis.com |------------------------------------------------  
   hfarkas at vnet.ibm.com   |     http://www.ims.advantis.com/~hfarkas
      henry at nhcc.com      |          http://www.nhcc.com/~henry 
- ---------------------------------------------------------------------------
PGP 6.2.2 Key fingerprint: AA D0 F5 44 C1 8C 11 52  B3 80 34 1C CE 38 EC 53
 Public key at: pgp-public-keys at pgp.mit.edu, and other popular key servers.
- ---------------------------------------------------------------------------
Not to worry, we'll just outlaw all unlicensed cryptography.  After all, it
works in France. You don't see weekly terrorist attacks over there any more
now do you ?             - futplex at pseudonym.com -
===========================================================================

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Auto-signed with Bryce's Auto-PGP v1.0beta

iQCVAwUBMJEgFqDthkLkvrK9AQF6ygP/VdVcox7kvuW7SWZsnHR2QddZuO0Xp60U
Y6VXMR56WwW8EPyJ4iTvIZ44Nqnt8XshQN22ZVLNQopb3uRpY+MQR68scm6YPBt/
4U+VvgOOopfHKTdJSpqJy8n4M1Y5o1UVnAUIL8oNUhQId55BvFK1GzdtsPRqZLYj
58SLD0+ub3U=
=EoR7
-----END PGP SIGNATURE-----

From jya at pipeline.com  Fri Oct 27 12:16:34 1995
From: jya at pipeline.com (John Young)
Date: Sat, 28 Oct 1995 03:16:34 +0800
Subject: QUB_ity
Message-ID: <199510271832.OAA25016@pipe4.nyc.pipeline.com>

   CJL has provided the Oct 13 Science article on "Quantum
   Computation," by David DiVincenzo of IBM Research, as
   summarized by the post of October 23.

   QUC_omp  (53 kb in three parts)

   (Math flubs by this ibm-qubity)

From tcmay at got.net  Fri Oct 27 12:18:41 1995
From: tcmay at got.net (Timothy C. May)
Date: Sat, 28 Oct 1995 03:18:41 +0800
Subject: Children's Rooms at Libraries Need Regulation
Message-ID: 

At 5:18 PM 10/27/95, Jim Ray wrote:

>Humorous sidenote: PRZ said that the Exon  bill is the
>equivalent of turning the entire Internet into the children's room
>at the public library. I will be getting a videotape of the show in
>about 2 weeks, and if anyone wants me to make them a copy please
>e-mail me (privately!) and I will try to oblige.

Actually, the "children's rooms" at public libraries are next on the list
to be regulated. Many of the books our children are reading feature
_talking animals_ and other examples of animism and pagan beliefs. Some
even have witches and goblins. That our tax dollars are being used to fund
pagan and heathen views is cause for alarm.

Thankfully, out here in California we are shaking off our liberal, heathen,
godless Jew commie system. Los Altos, a prosperous community in Silicon
Valley, recently banned the mention of Halloween in its schools. No
costumes, no heathen imitations, and NO DEVIL WORSHIP!

Hallelujah!

"Freedom is not the freedom to have wrong beliefs."

--Klaus!

From mab at research.att.com  Fri Oct 27 12:19:49 1995
From: mab at research.att.com (Matt Blaze)
Date: Sat, 28 Oct 1995 03:19:49 +0800
Subject: New release of CFS Unix encrypting file system available
Message-ID: <9510271856.AA24314@merckx.info.att.com>

Source code for the latest version (release 1.3.1) of CFS, the Cryptographic
File System, is now available upon request for research and experimental
use in the US and Canada.

CFS pushes encryption services into the Unix(tm) file system.  It
supports secure storage at the system level through a standard Unix
file system interface to encrypted files.  Users associate a
cryptographic key with the directories they wish to protect.  Files in
these directories (as well as their pathname components) are
transparently encrypted and decrypted with the specified key without
further user intervention; cleartext is never stored on a disk or sent
to a remote file server.  CFS employs a novel combination of DES
stream and codebook cipher modes to provide high security with good
performance on a modern workstation.  CFS can use any available file
system for its underlying storage without modification, including
remote file servers such as NFS.  System management functions, such as
file backup, work in a normal manner and without knowledge of the key.

CFS runs under SunOS and several other BSD-derived systems with NFS.
It is implemented entirely at user level, as a local NFS server
running on the client machine's "loopback" interface.  It consists of
about 5000 lines of code and supporting documentation.  You must have
"root" access to install CFS.

CFS was first mentioned at the work-in-progress session at the Winter
'93 USENIX Conference and was more fully detailed in:

    Matt Blaze. "A Cryptographic File System for Unix", Proc. 1st ACM
    Conference on Computer and Communications Security, Fairfax, VA,
    November 1993. (PostScript available by anonymous ftp from
    research.att.com in the file dist/mab/cfs.ps.)

and in

    Matt Blaze. "Key Management in an Encrypting File System", Proc.
    Summer '94 USENIX Tech. Conference, Boston, MA, June 1994.
    (PostScript available by anonymous ftp from research.att.com
    in the file dist/mab/cfskey.ps.)

Version 1.3 of CFS also includes ESM, the Encrypting Session Manager.
ESM provides shell-to-shell encrypted sessions across insecure links
and requires no OS or network support.  It is useful for typing cfs
passphrases when logged in over the network.  ESM needs RSAREF 2.0 to
compile and is tested only on SunOS and BSDI.  ESM is the first released
part of a suite of session encryption tools that are described in

    Matt Blaze and Steve Bellovin. "Session-layer Encryption."
    Proc. 1995 USENIX Security Workshop, Salt Lake City, June 1995.
    (PostScript is available from
    ftp://research.att.com/dist/mab/sesscrypt.ps)

The new version of CFS differs from the version described in the
papers in a few ways:

* The DES-based encryption scheme has been strengthened, and now
provides greater security but with the online latency of only single-DES.

* Support for the smartcard-based key management system is not
included and a few of the tools are not included.

* An impoved key management scheme now allows chaning the passphrase
associated with a directory.

* The performance has been improved.

* The security of the system against certain non-cryptanalytic attacks
has been improved somewhat. 

* User-contributed ports to a number of additional platforms.

* Hooks for adding new ciphers.

* 3-DES, MacGuffin, and SAFER-SK128 encryption options.

* Timeout options allow automatic detach of encrypted directories
after a set time or period of inactivity.

CFS is distributed as a research prototype; it is COMPLETELY
UNSUPPORTED software.  No warranty of any kind is provided.  We will
not be responsible if the system deletes all your files and emails the
cleartext directly to the NSA or your mother.  Also, we do not have
the resources to port the software to other platforms, although you
are welcome to do this yourself.  The software was developed under
SunOS and BSDI, and there are also unsupported user-contributed ports
available for AIX, HP/UX, Irix, Linux, Solaris and Ultrix.  We really
can't promise to provide any technical support at all, beyond the
source code itself.  We also maintain a mailing list for CFS users and
developers; subscription information is included with the source code.

Because of export restrictions on cryptographic software, we are only
able to make the software available within the US and Canada to US and
Canadian citizens and permanent residents.  Unfortunately, we cannot
make it available for general anonymous ftp or other uncontrolled
access, nor can we allow others to do so.  Sorry.

Legal stuff from the README file:

 *              Copyright (c) 1992, 1993, 1994, 1995 by AT&T.
 * Permission to use, copy, and modify this software without fee
 * is hereby granted, provided that this entire notice is included in
 * all copies of any software which is or includes a copy or
 * modification of this software and in all copies of the supporting
 * documentation for such software.
 *
 * This software is subject to United States export controls.  You may
 * not export it, in whole or in part, or cause or allow such export,
 * through act or omission, without prior authorization from the United
 * States government and written permission from AT&T.  In particular,
 * you may not make any part of this software available for general or
 * unrestricted distribution to others, nor may you disclose this software
 * to persons other than citizens and permanent residents of the United
 * States and Canada. 
 *
 * THIS SOFTWARE IS BEING PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED
 * WARRANTY.  IN PARTICULAR, NEITHER THE AUTHORS NOR AT&T MAKE ANY
 * REPRESENTATION OR WARRANTY OF ANY KIND CONCERNING THE MERCHANTABILITY
 * OF THIS SOFTWARE OR ITS FITNESS FOR ANY PARTICULAR PURPOSE.

If you would like a copy of the CFS source code, please read to the end
of this message and then send email to:

	cfs at research.att.com

DO NOT REPLY DIRECTLY TO THIS MESSAGE.  You must include a statement
that you are in the US or Canada, are a citizen or legal permanent
resident of the US or Canada, and have read and understand the license
conditions stated above.  Be sure to include an email address in a US-
or Canada-registered domain. The code will be sent to you via email in
a "shar" shell archive (a little over 300K bytes long).

From aba at atlas.ex.ac.uk  Fri Oct 27 13:23:21 1995
From: aba at atlas.ex.ac.uk (aba at atlas.ex.ac.uk)
Date: Sat, 28 Oct 1995 04:23:21 +0800
Subject: CJR returned to sender
Message-ID: <10401.9510271935@exe.dcs.exeter.ac.uk>

Josh Osborne  writes on cpunks:
> [...]
> 
> (Also we may find a better quality shirt printer and actually be
> able to print readably not only CODE128 barcodes, but some of the
> more advanced encoding methods that store as much as 40K a page...
> how big is the PGP source?)

Well the DOS PGP.EXE binary should do (no need for source, as it is
uses keysizes greater than allowed by ITAR already, so ability to
increase key sizes is not required for ITAR applicability).  It's 94k
pkzipped.  Front and back print on a T-shirt would give you 80k.  You
could probably tweak something to get it on a shirt.  Dunno if it
would read printed on a shirt.

It would be fun to see what it looked like a sheet of paper tho'.

Anyone happen to have code to do some of these 2d barcoding things?
Or are they all proprietry?

> >If the CJR for the t-shirt is ultimately denied, ditto?
> 
> That would be much better.  More free publicity.  An example of how
> impossabble it is to enforce the ITAR that anyone should be able to
> understand.

Yeah, I think that would be good anti-ITAR publicity.

> >The t-shirt joke is unlikely to help. (For all those who commented that
> >wearing the munitions shirt is rilly, rilly kool, I say "Great!" Wear it in
> >the mosh pits, just lie to people about how the t-shirt "has been
> >classified as a munition." It hasn't been as of this writing.)
> 
> [...]
> 
> (and yeah it is a shame the shirt actually says "has been classified",
> I had thought I said "qualifyes as a" which would have been correct -
> but that may just be my revisionest memory kicking in)

The wording on the shirts are: "...is a munition" and "...is
classified as a muntion".  Is that what you meant, that "this shirt is
a muntion" is misleading?

The "has been classified" was wording that Don Henson used in his
earlier ads, but did not appear on any of the shirts (AFAIK).

Joel Furr's shirt says:

 THIS SHIRT IS A MUNITION

Don Henson's says:

     WARNING
    THIS SHIRT 
       IS A 
     MUNITION 

My shirts say:

                WARNING
THIS SHIRT IS CLASSIFIED AS A MUNITION AND
   MAY NOT BE EXPORTED FROM THE UNITED
  STATES, OR SHOWN TO A FOREIGN NATIONAL

I think Raph sent them one of Joel's, so it says "this is shirt is a
munition", rather than "...has been classified...".  Perhaps some
people think that this too is inaccurate?

Adam
--
#!/bin/perl -s-- -export-a-crypto-system-sig -RSA-3-lines-PERL
$m=unpack(H.$w,$m."\0"x$w),$_=`echo "16do$w 2+4Oi0$d*-^1[d2%Sa
2/d0
Message-ID: <199510271954.PAA20647@universe.digex.net>

Matt Blaze writes:
>CFS pushes encryption services into the Unix(tm) file system.  It
>supports secure storage at the system level through a standard Unix
>file system interface to encrypted files.  Users associate a
>cryptographic key with the directories they wish to protect.  Files in
>these directories (as well as their pathname components) are
>transparently encrypted and decrypted with the specified key without
>further user intervention; cleartext is never stored on a disk or sent
>to a remote file server.  CFS employs a novel combination of DES
>stream and codebook cipher modes to provide high security with good
>performance on a modern workstation.  CFS can use any available file
>system for its underlying storage without modification, including
>remote file servers such as NFS.  System management functions, such as
>file backup, work in a normal manner and without knowledge of the key.

What happens to hard links?

mkdir foo bar
CFS_set_directory_key -directory ./foo -key foo-key
CFS_set_directory_key -directory ./bar -key bar-key
cp /etc/passwd ./foo/test1
ln ./foo/footest ./bar/bartest
cmp ./foo/footest ./bar/bartest

From cman at communities.com  Fri Oct 27 13:56:47 1995
From: cman at communities.com (Douglas Barnes)
Date: Sat, 28 Oct 1995 04:56:47 +0800
Subject: Electric Communities (was: COS_sec)
Message-ID: 

FWIW, this is the company I work for. Not a bad article; more
info is available at: http://www.communities.com/. Three of
the nine people who work here are long-time subscribers to this
list... I was recruited at a c'punks Bay Area meeting.

--doug "member of the cryptographic staff" barnes

>      Electric Communities began work began in 1993 on the
>      Cyberspace Operating System, or COS, designed to manage
>      the resources of shared computing -- like security and
>      bandwidth -- just as operating systems like the
>      Macintosh OS or Windows 95 manage resources inside a
>      desktop PC. The team is inventing some technology,
>      including a programming language (compatible with Sun
>      Microsystems' new Java language for Internet
>      applications) and a design concept for software building
>      blocks which it is in the process of patenting. In
>      addition, staff cryptographers are weaving encryption
>      throughout the system to make it absolutely secure and
>      private.
>
>
>   COS_sec  (6 kb)

From nobody at REPLAY.COM  Sat Oct 28 05:50:17 1995
From: nobody at REPLAY.COM (Anonymous)
Date: Sat, 28 Oct 95 05:50:17 PDT
Subject: EE Times on IDEA
Message-ID: <199510281250.NAA14958@utopia.hacktic.nl>

Electronic Engineering Times
Oct 23, 1995 p. 66

T.R MADHUSUDAN SASTRY,
T. GANESAN, B.MADHUKAR
AND N. SRINIVASA

MOTOROLA INDIA ELECTRONICS Pvt. Ltd.
BANGALORE, INDIA

Time is right for a good, secure 'Idea'

Computers are the medium in which almost all of today's business deals and international transaction transpire. That calls for the development of secure systems, which protect data from being accessed by unautho-rized users. Digital Encryption Standard (DES) is a cipher system that uses a 64-bit-long secret key. With present comput-er technology, it is not difficult to break DES by trying all possible keys. That made cryptographers look for different encryption algorithms that take a long time for today's computers to break the code. The International Data Encryption Algorithm (Idea) is a private key-block ciphering scheme, which is computationally highly secure since it uses a 128-bit-long secret key. The brute force method of breaking the code, (trying all possible combinations as keys) would require 10^24 years for a chip that can test a billion keys per second. The design philosophy of Idea is to niix the operations from different algebraic groups to add confusion and di!
 ffusion to the input data. The operations are addition modulo, multiplication modulo, and exclusive OR (XOR).

We have implemented Idea in electronic-code-book (ECB) mode on the Motorola DSP 561xx family of processors. In ECB mode, a 64 bit input block is encrypted to generate a 64-bit output block that is transmitted to the receiver through insecure but error free channels. In Idea, all the algebraic operations work with 16-bit blocks of data. That makes the algorithm efficient on a 56 to DSP, which has a very good instructioln set to perform the addi-tion modulo 2^16, multiplication modulo 2^16 + 1 and 16-bit XOR operations.

The Idea is a block-cipher scheme in which the incoming data is divided into blocks of 64 bits and fed as input to the encryption algorithm (see figure). The 64 bit data X= (X1 X2 X3 . . . X64) is initially divided into 4 subblocks X1, X2, X3 and X4each of 16 bits. These four sub-blocks become input for the first round of operation. In each round, each subblock is added and multiplied under modulo fields with key subblocks, thus adding more confusion and diision.

The sequence of operations for the first round is given below; it's the same for all rounds of operations except for different key subblocks.

[1] Multiply X1 and Kl, (first key subblock Zl^l) under modulo 2^16 + 1
[2] Add X2 and K2 (Z2^1) under modulo 2^16
[3] Add X3 and K3 under modulo 2^16  
[4] Multiply X4 and K4 under modulo 2^16 + 1
[5] XOR the results of step 1 and step 3
[6] XOR the results of step 2 and step 4
[7] Multiply the results of step 5 and K5 under modulo 2^l6 + 1
[8] Add the results of step 6 and step 7
[9] Multiply the re sults of step 8 and K6 under modulo 2^16 + 1 .
[10] Add the results of step 7 and step 9 under modulo 2^16
[11] XOR the results of step 1 and step 9
[12] XOR the results of step 3 and step 9
[13] XOR the results of step 2 and step 10
[14] XOR the results of step 4 and step 10

The results of each round from steps 11, 12, 13, and 14 form the  input blocks for the second round of opera-
tion after swapping the two inner blocks (see figure). After eight rounds are over, the following transformation has to be done before taking output cipher text. It should be noted that swapping is not done for the
last round.

[1] Multiply X1 and the 49th key subblock K49 (Z1^9)
[2] Add X2 and the 50th key subblock to k50 (Z2^9)
[3] Add X3 and the 51st key subblock k51 (Z3^9)
[4] Multiply X4 and the 52nd key subblock K51(Z3^9)

The decryption algorithm is also exactly the same except for the change in the subblock keys. From each of the key subblocks in the encryption, either additive inverse or multipli
cative inverse is used. For example, the subblock key used to multiply this data subblock is re placed with its multiplicative inverse. Also the order in which that multiplicative and additive inverse occurs in the decryption algorithm takes care of the shuffling of the intermediate data subblocks.

As stated earlier the encryption key is 128 bits long. The 52 encryption subblock keys are derived from the encryption key, and the corresponding subblock keys are derived from the encryption-key subblocks. The key subblocks for the first round of encryption are derived by dividing the 128-bit-long key into 16-bit blocks. Then, for every next round, the encryption key is circularly shifted by 25 bits and then divided into 16-bit blocks to yield encryption-key subblocks. In the last round, only the first four key subblocks are generated.

The Idea can be implemented in all three modes of operation: ECB, output-feedback mode (OFB) and cipher-feedback mode (CFB). In ECB, the input is split into 64-bit blocks, encrypted and transmitted. In CFB, the output cipher text from one block of encryption is used to form part of in input block. And the output of the algorithm is XORed with the input plain text, and transmitted. Similarly, the feedback is taken after
the XORing operation. In thepresent implementation, only ECB mode is done, which is the fastest among the three.

Since all the operations are on 16-bit blocks, the powerful instruction set of 561xx can beused for efficient implementation. The modulo 2^16 + 1 multiplication operation is used many times, and it is computationally intensive when compared with XOR and modulo 2^16 addition. The fixed-point multiplication construction of 561xx can be utilized to perform 32-bit multiplication.

The modulo 2^16 addition operation can be done just by ignoring the carry of 16-bit addition in 561xx. The XOR operation is also supported in one instruction as in any other DSP processor. Hence all three algebraic operations can be implemented efficiently using the instruction set of 561xx

Again the decryption algorithm is exactly the same as the encryption algorithm, except, that the decryption-key sub block is used instead of encryption. The whole program can be reused for decryption by changing the input variables and output variables.

Circular shift 
The main computation in encryption-key subblock generation is the circular shift of the l28-bit-long key. The encryption key can be stored as eight words in memory. In the present implementation, instead of shifting the key circularly, the mask patterns are used to pick up suitable key subblocks. That is, the second set of eight key subblocks can be generated by picking up 16 bits from the ninth bit of the second word of the encryption key.                 

Hence, for each round, we need to multiply each encryption key word by a suitable mask pattern, and left shift it with a suitable number of bits. The left-shifting operation for any arbitrary number of bits can be performed using the integer multiplication. Storing the mask patterns can be eliminated by using the shifted version
of left-shift constants as right-shift constants. The left-shift constant is multiplied with the current encryption-key word, and the right-shift constant is multiplied with the next keyword, and both are combined to
generate one key subblock. The right-shift constants are gotten by right shifting the left shift constant by 1 bit, which considerably reduces the computation involved. The current implementation of Idea in ECB on Motorola's DSP 56166 running at 60 Mhz supports up to 625 kbits/second in full-duplex mode. That is 3.6
times faster than using the DES algorithm.

From hallam at w3.org  Fri Oct 27 15:02:28 1995
From: hallam at w3.org (hallam at w3.org)
Date: Sat, 28 Oct 1995 06:02:28 +0800
Subject: Rabin Patents.
Message-ID: <9510272053.AA28938@zorch.w3.org>

Anyone know who is currently claiming Patent rights over the 
Rabin public key encryption and signature schemes? Is it RSADSI
or Cylink ... or both?

	Phill 

From vznuri at netcom.com  Fri Oct 27 15:02:35 1995
From: vznuri at netcom.com (Vladimir Z. Nuri)
Date: Sat, 28 Oct 1995 06:02:35 +0800
Subject: newsweek oct 30 Levy digital cash article
In-Reply-To: 
Message-ID: <199510272049.NAA29753@netcom7.netcom.com>

S.L.:
>>also, my question about whether one loses the downloaded Chaumian bucks
>if one's hard drive crashes was answered in the affirmative by Levy.
>
>But as I said, if the drive is backed up you don't lose it. It's my 
>understanding this is the case with the current Digicash/Twain bucks.  
>But not necessarily with all implementations.

you apparently didn't notice but there were some other posts on this
list about writing down the random seed that a person used to generate
the cash, and then being able to restore the cash somehow based on knowing
the random seed, however privacy is sacrified in this case apparently.
this with the Chaumian implementation, from what I understood.

if this is true, I wanted to point out in my post that this is a property
that real cash does not have. you cannot ever say to your bank from which
you withdrew cash, "oops, I lost a piece, could you replace it? also, if
someone spends the piece that I lost, tell them they can't?"

how would the bank handle a situation in which the consumer says, "oops,
my hard drive was compromised. all of the following cash was NOT spent
by me." notice this is precisely what happens with stolen credit cards today
all the time. the bank, if it was real cash, would have to say, "sorry,
you're out of luck. it's your responsibility to keep your cash secret".

or, the bank might say, "oh, well, that cash was not spent yet. we can issue
a replacement and bar the cash from being spent". this idea of "replacing"
cash is of course unique to the electronic realm. if the bank does it,
the consumer would be required to notify the bank before the cash is 
spent, again another unusual property unique to e-cash.

I would suggest to all companies developing e-cash that they print up
a carefully designed FAQ in which their cash properties 
are compared directly with parallel
properties of credit cards such as like the item above, because the
consumer is of course very familiar with credit cards. (this will be very
crucial for longterm customer education and acceptance imho. otherwise
the customer may make assumptions like, "since the cash comes on a card
it behaves like a credit card", etc.)

I would like to see someone elucidate what happens with lost Chaumian cash
in a detailed post (the oneliners I saw so far don't address the complexity 
and seriousness of this issue. this is a really significant issue with digital 
cash IMHO that will become very obvious once people who were used to the 
"mushiness" of credit card transactions switch to cash).
there seem to be many caveats with this "restoration".

one immediate problem I can imagine: the recent netscape bug showed
very well that a short random number generation process can be hacked.
so in other words, if the random numbers are short enough to write down,
it makes me wonder about the security of the cash generated from this
seed.

>This "lose your money" with digital cash really does seem to get to 
>people. I always point out that when you take $ out of an ATM machine, 
>you don't expect to get it back if you lose it.  For those forms of 
>e-money that are irretrevable when lost users are warned not to download 
>huge amounts. 

yes, it is clearly an emotional issue. the problem with a lot of technology
is that people are very emotional and irrational, and hyperactively so when it
comes to spending money. all marketing campaigns are designed to 
capitalize on this. various competitors can be tainted merely by
cheap psychological ploys that have no basis in fact. (the back and
forth between AT&T, MCI and Sprint and other competitors is an example
of the endless mudslinging, marginally based on reality, that can ensue.)

as I wrote in my earlier post, the key is to let people know of the weaknesses
in the product ahead of time so they are prepared. and the analogies that
you offer are precisely the kind the company can give to the customer to
make them feel more comfortable that "this stuff is more convenient than
real cash and not really any more dangerous". it's critical that they do
so ahead of time however, before the customer gets zapped by his own naivete.

>Question: will people's worries about losing their e-money lead them to 
>accept a higher degree of tracibility as a tradeoff?  

that's exactly the issue I tried to raise in my post, unfortunately perhaps in
not the crisp way you do here. (of course, you're the one that makes a living
off your prose, heh.)

one can see advertising as a kind of yin/yang game. you have to imagine
that if your competitor says, "gosh, you could lose cash with so-and-so's
system", you can always reply "yes, but you retain privacy-- can you do
that with so-and-so's system"?  digital cash is not a panacea. it is
in fact a design compromise that simply applies more importance to
various aspects of transaction capabilities: ease of use, privacy, etc.

checks and cash are at two ends of the economic transaction spectrum.
in contrast to other cypherpunks I don't really see either as intrinsically
superior to the other. many businesses may *never* end up using digital
cash in certain transactions (i.e. with other companies, not individual
buyers) for traceability reasons. it seems to me
there are many agreements in which hiding the identity of one or both
parties is simply intrinsically unacceptable to both, and no amount of
handwaving smoke-and-mirrors appeals to magic "reputation agencies" will
completely alleviate this.

so my bottom line is that I think digital cash is going to become a
very, very important part of the future economic ecology, but it will
coexist with other methods. it may very well become the dominant method,
but I suspect there will be significant areas of commerce that actively
resist digital cash technology out of the preferences of all parties.

something the hardcore cypherpunks in general fail to consider, that was 
brought out in a great article in the WSJ about the counterfeit 
$100 superbills circulating:
the cash aspects of the global economy are negligible in comparison to
"identified" transactions such as through credit and checks. (hence the
treasury's lukewarm approach to stopping counterfeiting, which scares
the willies out of me personally). there is absolutely an *enormous*
dedication to "identified" transactions in the world today, and cypherpunks
seem to me to be somewhat misguided in the ways they exalt cash.

it is true that cash is the medium of choice for the individual, but the
vast majority of economic transactions are *not* made by the individual
in virtually any civilized society. digital cash may change this slightly,
but not significantly, I suspect. businesses exchange money as part of
complex agreements and contracts in which liability is a key ingredient.
liability is an exceedingly problematic issue with digital cash. if anyone
is going to create a widespread cash economy based on total anonymity
they have an uphill battle easily far more difficult than Chaum has
encountered so far. (remember Chaum only implements "semi-anonymity", 
anonymity on payer side but not payee side).

--

anyway, congrats on the fine article SL. you get my "honorary 
cypherpunk of the week" award for the article 

From bluebird at alpha.c2.org  Fri Oct 27 15:33:55 1995
From: bluebird at alpha.c2.org (bluebird at alpha.c2.org)
Date: Sat, 28 Oct 1995 06:33:55 +0800
Subject: Need Mail-to-News gates
Message-ID: <199510272159.OAA06298@infinity.c2.org>

Could someone PLEASE netmail me some _known reliable_ gates that use the
straight netmail address format (alt.whatnot at bosco.kollege.edu)?

All of the old reliables are shut down and none of the ones listed in
the last remailer helpfile I got work either:

group.name at news.demon.co.uk
group.name at dispatch.demon.co.uk
group.name at bull.com
group.name at cass.ma02.bull.com
group.name at paris.ics.uci.edu
group.name at crs4gw.crs4.it
group.name at berlioz.crs4.it
group.name.usenet at canaima.Berkeley.EDU

NONE of these work, or were nonfunctional when I tested them, anyway.

I use the other gates like mail2news at utopia.hacktic.nl with the
Newsgroups: field format, but the straight address format is useful for
some other purposes.

Thanks.

From cman at communities.com  Fri Oct 27 15:40:18 1995
From: cman at communities.com (Douglas Barnes)
Date: Sat, 28 Oct 1995 06:40:18 +0800
Subject: newsweek oct 30 Levy digital cash article
Message-ID: 

Vlad the Inhaler writes:
>
>you apparently didn't notice but there were some other posts on this
>list about writing down the random seed that a person used to generate
>the cash, and then being able to restore the cash somehow based on knowing
>the random seed, however privacy is sacrified in this case apparently.
>this with the Chaumian implementation, from what I understood.
>

I would not say that privacy is "sacrificed" if, in fact, Digicash
has implemeneted this "write down the original random seed" backup
method. Worst case scenario -- you write down the seed, and when the
police break down your door, they find that you've written it down.
Well, if things have progressed to that point, you're in pretty
serious trouble anyhow, and if you're expecting this to happen you
have a simple remedy -- back up & encrypt your wallet rather than
writing the seed down. Or, put the seed in a little text file,
encrypt the text file, and back it up.

I suspect, however, that this means that the Digicash wallet doesn't
pick up new bits of entropy to "groom" it's random state. Also, it
was unclear where this state came from, but it's hopefully not just
text entered by the user. (I could see getting the state from something
like keystrokes or mouse clicks, then having the user write down a
checksummed, error-corrected string as a preferred alternative.)

From vznuri at netcom.com  Fri Oct 27 16:30:20 1995
From: vznuri at netcom.com (Vladimir Z. Nuri)
Date: Sat, 28 Oct 1995 07:30:20 +0800
Subject: groupware position available in Boston
Message-ID: <199510272309.QAA16720@netcom11.netcom.com>

I recently got word of an interesting groupware development position
in Boston that someone here may be able to benefit from. feel free
to pass on this info.

(contrary to some here who are not impressed with groupware application
potential, in my estimation groupware is soon going be a key "killer app" 
in cyberspace, perhaps the "next" one after Netscape, driving key 
technological advancement in network & software development...  in my
opinion virtually every significant and valuable aspect of the internet
can be boiled down into a subset of the functions of groupware.)

===

From: mike at kni.mv.com (Mike Hren)

...
We are starting a company called Emergent
Systems and are looking for technical partners to help turn our vision into
reality.

We're developing a meta-groupware application that seeks to accelerate the
learning of a workgroup. Called a Discovery Acceleration System, the idea
is to use a text engine to synthesize the collective email dialogue
(voicemail later) of a workgroup into its core concepts (Concept Map) that
can be visualized, hypertext linked to related information sources, and
used as a prioritizer of unsolicited email based on conceptual relevance.
Just as knowledge is born of chaos, this Concept Map emerges from the
workgroup's daily interaction--as opposed to being externally defined by a
static knowledge base.

In a dynamic sense, since the Concept Map is used as a distributed Linker
and Lens between workgroups, it also enables a system of interaction to
emerge at the organizational level.

We are looking for someone with software development experience, and
interest in information retreival, data visualization, groupware, or
messaging systems. Since most of the components of this system are
commercially available, integration is more important than theoretical
development.  Also, a desire to be part of a start-up effort is a must.

....

If you or anyone you know might be
interested, please email a resume and description of interest.  Thanks for
your time.

Mike Hren
President
Emergent Systems, Inc.

From frogfarm at yakko.cs.wmich.edu  Fri Oct 27 16:35:28 1995
From: frogfarm at yakko.cs.wmich.edu (Damaged Justice)
Date: Sat, 28 Oct 1995 07:35:28 +0800
Subject: POINTER: The Money Laundromat
Message-ID: <199510272248.SAA32101@yakko.cs.wmich.edu>

J. Orlin Grabbe's essay, "The Money Laundromat", as published in the
November 1995 issue of Liberty, was sent to me via e-mail by someone
who prefers to remain anonymous. After checking for accuracy against
my own hard copy, I have posted it to the following Usenet newsgroups:

alt.security.pgp
alt.society.sovereign
alt.society.anarchy
talk.politics.crypto

I will be making this article available on my Web page shortly as well.
The article covers both the threat and the promise of digicash, with
much detail devoted to electronic surveillance and financial tracking
via PROMIS software. This single paragraph summarizes rather well:

"...the coming battle over financial footprints is inevitable, and perhaps
inevitably bloody. But in the end it is the money laundering regulations that
will have to go. For one thing, advances in the technology of anonymity are
putting financial privacy within the reach of everyone. For another, there is
a growing awareness that the existing laundering statutes have little or no
effect on terrorism or drug-dealing, but instead are related to an upswing in
government-sponsored harassment of targeted political groups."

-- 
http://yakko.cs.wmich.edu/~frogfarm  ..for the best in unapproved information
 S..O).... The statist wields a bad law! -- More --
 @.../.".. You quickly protect your money pouch! -- More --
 .$*...].. The statist vanishes in a puff of smoke. "Greedy bastard!"

From mab at crypto.com  Fri Oct 27 16:38:28 1995
From: mab at crypto.com (Matt Blaze)
Date: Sat, 28 Oct 1995 07:38:28 +0800
Subject: DigiCrime web page
Message-ID: <199510272320.XAA29752@crypto.com>

Arjen Lenstra's startup, DigiCrime, full service criminal computer
hacking organization now has a web presence, thanks to to the efforts
of its theif scientist, Kevin McCurley.

http://www.digicrime.com/

-matt blaze, president of vice

From zxmjn11 at here.or.there  Fri Oct 27 18:47:24 1995
From: zxmjn11 at here.or.there (someone)
Date: Sat, 28 Oct 1995 09:47:24 +0800
Subject: Encrypted TCP Tunneler
In-Reply-To: 
Message-ID: 

Hi,

i am using a prog called twinsock to have an internet connection via my 
shell account. The program provides a winsock for my windows progs and it 
comes with the complete source. When I first started to use it, I thought 
that it must be fairly easy to add some packet encryption to this 
program. But then I realized that it wouldnt work over a tcp/ip 
connection, only over a telephone line. But maybe the twinsock code might 
be a good starting point for some encrypting winsock. Unfortunately, I am 
not a good enough programmer to estimate how much work it is to come up 
with such an enhanced winsock or even start to make one myself.

Stephan

From usura at utopia.hacktic.nl  Fri Oct 27 19:09:18 1995
From: usura at utopia.hacktic.nl (User A.)
Date: Sat, 28 Oct 1995 10:09:18 +0800
Subject: Need Mail-to-News gates
Message-ID: <199510280149.CAA06177@utopia.hacktic.nl>

You sez:
: On Fri, 27 Oct 1995 bluebird at alpha.c2.org wrote:

: > Could someone PLEASE netmail me some _known reliable_ gates that use the
: > straight netmail address format (alt.whatnot at bosco.kollege.edu)?

: If someone will direct me to sources, I'll try and setup a gate. (We use 
: INN).

'ftp.hacktic.nl/pub/replay/remailer/mail2news.shar

-AJ-

From sameer at c2.org  Sat Oct 28 01:00:11 1995
From: sameer at c2.org (sameer)
Date: Sat, 28 Oct 1995 16:00:11 +0800
Subject: SSL Remailer interface w/premail
Message-ID: <199510280713.AAA18017@infinity.c2.org>

https://www.c2.org/remail/by-www.html

	Note that this uses SSL and that messages are encrypted using
premail -- the entire remailing chain is not in the clear
anymore. This is still a single point of failure system, but secure
against attacks which do not involve the compromise of c2.org. (Unlike
the non-encrypting one on http://www.c2.org/remail/by-www.html)

-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:     510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer at c2.org

From nobody at alpha.c2.org  Sat Oct 28 06:15:38 1995
From: nobody at alpha.c2.org (Anonymous)
Date: Sat, 28 Oct 1995 21:15:38 +0800
Subject: Diffie-Hellman Key Generation
In-Reply-To: 
Message-ID: <199510281301.GAA12933@infinity.c2.org>

> Finally, I'm basing this on comments in 'Applied Cryptography' that D-H
> keys should be at least 512 bits and preferably 1024. How does the
> difficulty of breaking a D-H exchange with a 512 bit key compare to
> breaking a 512 bit RSA key ?

Calculating discrete logarithms is a bit more difficult than factoring.
So a 512-bit DH modulus will give you somewhat more security than a 512-bit
RSA key.  I'm not sure how much, probably not a lot.

From BELL at odo.law.udayton.edu  Sat Oct 28 08:58:08 1995
From: BELL at odo.law.udayton.edu (Tom Bell)
Date: Sat, 28 Oct 1995 23:58:08 +0800
Subject: S. 1284 To Amend (C) Act
Message-ID: <14ADF0902256@odo.law.udayton.edu>

The 9/28/95 Congression Report states that Senators Hatch and Leahy 
have introduced a bill to amend the Copyright Act in accord with the 
suggestions of the recent White Paper on the National Information 
Infrastructure.  In relevant part, S. 1284:  1) makes transmission of copies a 
type of publication (and thus potentially a means of infringing a 
copyright); and 2) prohibits the importation, manufacture, or 
distribution of any device the primary purpose of which is to 
deactivate any technological protections that prevent or inhibit the 
violation of copyrights.

Though I can imagine cypherpunks objecting to the first of these two 
provisions, I'm especially interested in how you regard the 
second.  Imagine that Microsoft devised a program to prevent 
unauthorized copying of its software, and that you (perhaps in 
response to another of Sameer's contests!) wrote a program to 
counteract it.  It looks as the proposed law would forbid your 
counter-programming.  Bob would thus find it easier to sell defective 
copyright protection devices.

I'm thinking of writing an article about the White Paper and S. 1284, 
arguing that cypherpunks render a valuable public service in finding 
gaps in copyright protection, and that they therefore ought not be 
forbidden from pursuing their research.  I invite you to email me privately if 
you have a strong opinion about the proposed changes to the Copyright 
Act. I've attached a copy of the proposed s1201 below.

In a related vein, Senators Leahy and Feingold have introduced S. 
1122, which criminalizes willful infringements that do not have the
purpose of commercial gain.  This aims to close a percieved loophole 
under the current law, by which LaMacchia was able to distribute
copyrighted works.

S. 1284,  s1201:  "No person shall import, manufacture or distribute 
any device, product, or component incorporated into a device or 
product, or offer or perform any service, the primary purpose or 
effect of which is to avoid, bypass, remove, deactivate, or otherwise 
circumvent, without the authority of the copyright owner or the law, 
any process, treatement, mechanism or system which prevents or 
inhibits the violation of any of the exclusive rights of the 
copyright owner under section 106."

Tom W. Bell
Assistant Professor 
Law and Technology Program
UD Law School
bell at odo.law.udayton.edu

PGP fingerprint:
78 06 76 AC 32 38 A6 4C  B3 81 F4 1E 2E 27 AC 71

From moroni at prufrocks.scranton.com  Sat Oct 28 09:14:01 1995
From: moroni at prufrocks.scranton.com (Moroni)
Date: Sun, 29 Oct 1995 00:14:01 +0800
Subject: Returned mail: warning: cannot send message for 4 hours (fwd)
Message-ID: 

---------- Forwarded message ----------
Date: Fri, 27 Oct 1995 19:45:02 -0400
From: Mail Delivery Subsystem 
To: moroni at prufrocks.scranton.com
Subject: Returned mail: warning: cannot send message for 4 hours

    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Fri, 27 Oct 1995 15:38:29 -0400
from moroni at localhost

   ----- The following addresses had delivery problems -----
majordormo at toad.com.uc.edu  (transient failure)

   ----- Transcript of session follows -----
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

   ----- Original message follows -----

To: majordormo at toad.com.uc.edu
From: Moroni 
Date: Fri, 27 Oct 1995 15:38:27 -0400 (EDT)

subscribe Cypherpunks Deirdre A. Greene

From vznuri at netcom.com  Sat Oct 28 11:05:55 1995
From: vznuri at netcom.com (Vladimir Z. Nuri)
Date: Sun, 29 Oct 1995 02:05:55 +0800
Subject: newsweek oct 30 Levy digital cash article
In-Reply-To: 
Message-ID: <199510281748.KAA11693@netcom19.netcom.com>

>>
>>you apparently didn't notice but there were some other posts on this
>>list about writing down the random seed that a person used to generate
>>the cash, and then being able to restore the cash somehow based on knowing
>>the random seed, however privacy is sacrified in this case apparently.
>>this with the Chaumian implementation, from what I understood.
>>
>
>I would not say that privacy is "sacrificed" if, in fact, Digicash
>has implemeneted this "write down the original random seed" backup
>method. Worst case scenario -- you write down the seed, and when the
>police break down your door, they find that you've written it down.

point well taken, but I thought the original poster stated that one
had to reveal the blinding factors to the bank, which I interpreted
as "sacrificing" anonymity.

frankly, I didn't understand that whole procedure and that's why I
asked someone to go into detail about this very important aspect
of the cash beyond the 3 liners or so I have seen.

From cjs at netcom.com  Sat Oct 28 11:23:10 1995
From: cjs at netcom.com (cjs)
Date: Sun, 29 Oct 1995 02:23:10 +0800
Subject: S. 1284 To Amend (C) Act
In-Reply-To: <14ADF0902256@odo.law.udayton.edu>
Message-ID: <199510281800.LAA07028@netcom20.netcom.com>

> The 9/28/95 Congression Report states that Senators Hatch and Leahy
> have introduced a bill to amend the Copyright Act in accord with the
> suggestions of the recent White Paper on the National Information
> Infrastructure.  In relevant part, S. 1284: 1) makes transmission of
> copies a type of publication (and thus potentially a means of
> infringing a copyright); and 2) prohibits the importation,
> manufacture, or distribution of any device the primary purpose of
> which is to deactivate any technological protections that prevent or
> inhibit the violation of copyrights.
> 
> Though I can imagine cypherpunks objecting to the first of these two 
> provisions, I'm especially interested in how you regard the 
> second.

Its a mad mad mad mad mad world. I'd better order my cable descrambler
ahead of time.

Christopher

From frantz at netcom.com  Sat Oct 28 11:26:39 1995
From: frantz at netcom.com (Bill Frantz)
Date: Sun, 29 Oct 1995 02:26:39 +0800
Subject: Linux security issues
Message-ID: <199510281804.LAA14320@netcom15.netcom.com>

>>Actually keeping the pass phrase out of swap space is fairly easy (although
>>I havn't looked at the PGP code to see if it actually does this).
>>...
>>However, the pass phrase is not the only dangerous information.
>>...
>>N.B. This problem affects all virtual memory operation systems.
>
>Not all of them.  In at least one (VMS) you can pin pages in physical 
>memory,

Good point.  Too bad the invocations of pinning aren't portable.  Maybe in
the next POSIX.

>Actually, any OS that does I/O directly to user pages has that capability in 
>the kernel...

All the OSs I am familar with pin the pages only for the duration of the
I/O operation.  After the I/O has completed, the page can be swapped out. 
What you really need is to pin the page in memory (with an implicit
contract with your OS that it won't be written to swap space while it is
pinned), put the sensitive information in the page, use the information,
wipe the information, and un-pin the page.

I wonder if NSA has built a virus to collect PGP keys?

Bill

From stewarts at ix.netcom.com  Sat Oct 28 12:15:19 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Sun, 29 Oct 1995 03:15:19 +0800
Subject: digital cash and identity disclosure
Message-ID: <199510281848.LAA05019@ix7.ix.netcom.com>

At 08:53 AM 10/20/95 -0700, tomw at cthulhu.engr.sgi.com wrote:
>> I don't understand how this could happen? The two coins are identical
>> (as I understood it from the tech backgound of ecash). what has a double-
>> spended coin what a copied single-spended coin not has?

>The process of spending a coin is not simply that of transfering data.
>There is a complicated protocol in which Alice decrypts some of the
>identity information in the coin.  

There are several approaches - in the immediate-clearing model,
you can tell if someone's spent coin 111111111111 because the bank keeps
a record of which coins have been spent and refuses to pay anybody
who tries to spend the same coin later; this almost forces you to use
on-line clearing solutions.  Chaum's blinding protocols
make it possible for the bank to sign a coin without being able to
trace it to the person withdrawing the coin, so she can spend it anonymously.

Another model uses the protocols Tom described which place a random chunk
of the spender's identity into the coin - one chunk gives away no information,
but two chunks have an extremely high probability of doing so - so you
can go prosecute the guilty double-spender later (or just debit her account
twice...)
Then there are the non-anonymous models.
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From stewarts at ix.netcom.com  Sat Oct 28 12:15:32 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Sun, 29 Oct 1995 03:15:32 +0800
Subject: 50 attacks... [NOISE]
Message-ID: <199510281848.LAA04943@ix7.ix.netcom.com>

At 05:31 AM 10/20/95 -0700, tomw at engr.sgi.com wrote:
>To date, MD5 appears to be a secure hash.  If you manage to find a way
>to reverse it, please let us all know.

There are a couple of analytically known collisions, and a birthday attack
can generate more after a mere 2**64 tries or so; for some applications, 
this can be a problem (e.g. a if a collision between real input and
random-trash input can let you get the system to do something unexpected
by handing it the random-trash input.)

Also, you can easily MD5-hash a dictionary of a billion wimpy passphrases
to let you catch people who use wimpy passphrases, and similarly hash
a dictionary of a billion reasonably-probable plaintexts for applications
that have reasonably-probable plaintexts that leave the hashes in plain view
(e.g. checksums for messages like "send $X to account Y"); this kind of
attack works for any hash, including cryptographically strong hashes,
as long as the system being attacked lets you crack it by reversing a hash
and doesn't use salt in its hashes.

>Sure we spend a lot of money, but that doesn't mean | Tom Weinstein
>we *do* anything.  --  Washington DC motto          | tomw at engr.sgi.com

But Washington not doing anything is *good* :-)
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From rah at shipwright.com  Sun Oct 29 05:13:41 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Sun, 29 Oct 95 05:13:41 PST
Subject: Technology: The Great Deregulator
Message-ID: 

St. Pete (Peter Huber, that is) Speaks!

Cheers,
Bob Hettinga

--- begin forwarded text

Date: 27 Oct 1995 14:23:50 GMT
From: khh at access4.digex.net () (by way of rah at shipwright.com (Robert A.
Hettinga))
To: rah at shipwright.com
Subject: Technology: The Great Deregulator
Organization: Express Access Online Communications, Greenbelt, MD USA
Path:
sundog.tiac.net!daily-planet.execpc.com!news.moneng.mei.com!uwm.edu!chi-news
.cic.net!newsfeed.internetmci.com!in2.uu.net!news3.digex.net!access4.digex.n
et!not-for-mail
Newsgroups: alt.politics.economics
Lines: 91
NNTP-Posting-Host: access4-2.digex.net
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
X-Newsreader: Value-Added NewsWatcher 2.0b27.1+

     Following is an article by Peter Huber. More articles by Mr. Huber
can be seen at http://khht.com/huber/home.html.

   -----------

   The sun is finally setting on a dismal century of economic commissars.
   Not Russia's, ours. I mean the people who, for most of this century,
   controlled price and output in markets for trucking, air travel,
   railroads, telephone service, cable TV, natural gas and electricity.
   Until recently, these mammoth industries, representing a sizable
   fraction of the U.S. economy, had about as much to do with free-market
   competition as the steel industry in Stalingrad.

   It started with the Interstate Commerce Commission. Established in
   1887, the ICC was to be the federal antidote to rapacious railroad
   monopolies. Perhaps it was, for a while, but in the end it drove them
   into bankruptcy. Meanwhile, local, state and federal legislators set
   up baby ICCs left and right on the assumption that highways,
   pipelines, phone wires and power grids all required much the same
   handling as railway track. In track-like industries, monopolies were
   natural. Competition was wasteful. Commissions were smart enough to
   run things better.

   Most of the people who believed such things died years ago, but the
   government pyramids they built have endured. A great decommissioning
   of economic life in America is now under way. The job is almost
   finished for airlines and trucks. It's inching ahead in the
   communications arena. Electricity is just getting started. We'll find
   out in due course whether Newt Gingrich and Bob Dole can deregulate as
   boldly as Ted Kennedy and Jimmy Carter, who kicked off serious
   economic deregulation in the 1970s.

   As the Kennedy/Carter legacy confirms, the impetus for change isn't
   hatred of government. Nor can the decommissioning of America be blamed
   on right-wing capitulation to big business. We've just learned the
   hard lessons of commissariat collectivism, in much the same way as the
   Hungarians and the Czechs.

   Consumers end-run the regulators. Fed up with prices that force them
   to subsidize residential consumers, factories and hospitals cogenerate
   electricity in their heating plants. They install "private branch"
   telephone exchanges that displace about one-third of the phone service
   they'd otherwise buy from the local phone company. Landlords set up
   rooftop satellite dishes on apartment buildings and sell "private
   cable" service to tenants. When you mow your own lawn, regulators get
   trimmed too: There's no income tax for them to collect, no maternity
   leave to grant, no minimum wage to enforce.

   Technology outwits the regulators. Hub-and-spoke routing and
   yield-maximizing pricing schemes concocted on supercomputers that
   shattered the old Civil Aeronautics Board's point-to-point vision of
   how air travel should operate, and at what price. The FCC's vision of
   "local" broadcasting provided by a few, community-based stations
   collapsed when Ted Turner began bouncing his UHF station off a
   satellite and back down to cable systems nationwide. And billions of
   dollars of commission-prescribed prices will soon have to be
   rejiggered because smart-aleck programmers have worked out how to
   transmit two-way voice conversations live over the Internet. The
   commission's policy is to price voice connections about $ 4 an hour
   higher than "date," but digital technology obliterates the
   distinction.

   Regulators are cannibals. As commissions proliferate, they undercut
   each other. Long distance phone companies and "access providers" like
   Teleport expand under lenient federal control -- at the expense of
   local phone companies kept on a tighter leash by state commissions.
   Wireless phone service has been almost completely deregulated by its
   federal regulators, so it grows far faster than service by way of
   telephone pole, which remains heavily regulated under the price
   regulation maintained by one bureau of the FCC. Direct broadcast
   satellite, cable's competitor, is booming under the hands-off watch of
   another bureau of the same federal commission.

   Regulators invest badly. They direct utilities to put billions in
   overpriced power plants, inefficient wires and extravagant service out
   to the very last ranch at the end of nowhere. Cost is no object; it
   just gets dumped in the "rate base." Competition, when it arrives, is
   devastating, just as the fall of the Berlin wall was devastating to
   the factories that built Trabants.

   In these times of radical technological change, utility monopolies are
   as unstable as politburos. Many of the old-guard enterprises may still
   grow and prosper, but only if they learn to sell to a whole new class
   of buyers. Consumers, not commissars.

--
   Copyright 1995 by Peter Huber. Electronic copies of this document may
   be distributed freely, provided that this notice accompanies all
   copies.

--- end forwarded text

-----------------
Robert Hettinga (rah at shipwright.com)
Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
USA (617) 323-7923
"Reality is not optional." --Thomas Sowell
>>>>Phree Phil: Email: zldf at clark.net  http://www.netresponse.com/zldf <<<<<

From pierre at shell.portal.com  Sat Oct 28 14:17:32 1995
From: pierre at shell.portal.com (Pierre Uszynski)
Date: Sun, 29 Oct 1995 05:17:32 +0800
Subject: Anonymity: A Modest Proposal
Message-ID: <199510282018.NAA21600@jobe.shell.portal.com>

kelso (kelso at netcom.com) suggested:
[Let's split the message, get both parts independently to the
end-recipient and let him sort it out]

Thomas Grant Edwards (tedwards at Glue.umd.edu) continued:
[Well, let's just get it there still encrypted]

I'll continue in this direction:

My understanding is that it is a Good Thing for the last stage remailer
to be able to claim:  "I received high entropy stuff. There is no way I
could tell what it was. I just forwarded it. I just make sure I do not
forward low entropy stuff."  Furthermore, it would help everybody if
end-recipients were somehow able to signal whether they are or are not
willing to read clearly anonymous material (and are suckers for
pseudonyms :-)

The problem is that it is currently the last stage's responsibility
to decipher most messages, and it is very difficult (at best) to go
back and modify all mail and news readers so their user can shield
himself from anonymous stuff.

We could however provide servers that make it "Very Easy" or at least
easier for the end-recipient to make sense of split or still encrypted
email messages:

(In broad lines, depending on the remailer type.)
The end-recipient may receive one encrypted message, or k split parts of
a message that say, prominently at the top (ni the message body so that
braindead mail readers show it to their users):

"If you are the end-recipient for this email message, you can get it
decrypted by forwarding it as is to a Handyserver such as
handyserver at well.known.site.  Don't worry about formats, the server
knows what to do. If you received several such messages, forward all of
them one by one or together. They may all be parts of one message. The
server remembers parts for a week, while waiting for more parts, and
will respond when done."

Now, we need a way for this to work for the end-recipient but not for
the last stage remailer. How about the message sender sending, through
the remailer network, to the Handyserver (How about Johnnyserv as an
other possible name :-), the decryption key, the end-recipient email
address and name, and the first few bytes of the encrypted messages.
The Handyserver authenticates service requests with some heuristic
based on name and email, and knows which key to apply based on the
message's first few bytes. That's extremely weak authentication but it
usually takes no effort by the end-recipient and the last stage
remailer can now say "I cannot attempt to get all my traffic through
Handyservers. Not only it would be very time consuming, but I would
have to illegally forge the recipient's address and the Handyserver
would forward the decrypted version directly to the end-recipient
anyway." The Handyserv can also keep a list of tokens publically posted
for the sender to be able to confirm whether his message was or was not
decrypted (that's an acknowledgement for a successful transmission
through the remailer system, too.)

In summary, the Handyserver provides a "mild" function: Its logs could
permit the identification of the last stage remailer, but so what, the
end-recipient had this info already. The last stage remailer now is
safer.  And the end-recipient has to choose and voluntarily get the
message decrypted.

That could take care of email. Maybe something similar is possible for
news (more or less the way rot13 worked, way back then, in the good old
times when it was deemed sufficient to protect sensitivities.)

Pierre.
pierre at shell.portal.com

From nobody at c2.org  Sat Oct 28 14:19:34 1995
From: nobody at c2.org (Anonymous User)
Date: Sun, 29 Oct 1995 05:19:34 +0800
Subject: Electric Communities (was: COS_sec)
Message-ID: <199510282005.NAA25047@infinity.c2.org>

In article 
cman at communities.com (Douglas Barnes) wrote:
>
>FWIW, this is the company I work for. Not a bad article; more
>info is available at: http://www.communities.com/. Three of
>the nine people who work here are long-time subscribers to this
>list... I was recruited at a c'punks Bay Area meeting.
>
>--doug "member of the cryptographic staff" barnes
>
>>      Electric Communities began work began in 1993 on the
>>      Cyberspace Operating System, or COS, designed to manage
>>      the resources of shared computing -- like security and
>>      bandwidth -- just as operating systems like the
>>      Macintosh OS or Windows 95 manage resources inside a
>>      desktop PC. The team is inventing some technology,
>>      including a programming language (compatible with Sun
>>      Microsystems' new Java language for Internet
>>      applications) and a design concept for software building
>>      blocks which it is in the process of patenting. In
>>      addition, staff cryptographers are weaving encryption
>>      throughout the system to make it absolutely secure and
>>      private.
>>
>>
>>   COS_sec  (6 kb)
>
>

Great! Just what we need! java wannabees!

Ripoffs of secondrate, insecure software by thirdrate people!

Hey Dougie, "invented" any viruses lately?

From nobody at c2.org  Sat Oct 28 14:31:02 1995
From: nobody at c2.org (Anonymous User)
Date: Sun, 29 Oct 1995 05:31:02 +0800
Subject: New release of CFS Unix encrypting file system available
Message-ID: <199510282012.NAA25761@infinity.c2.org>

In article <199510271954.PAA20647 at universe.digex.net>
Scott Brickner  wrote:
>Matt Blaze writes:
>>CFS pushes encryption services into the Unix(tm) file system.  It
>>supports secure storage at the system level through a standard Unix
>>file system interface to encrypted files.  Users associate a
>>cryptographic key with the directories they wish to protect.  Files in
>>these directories (as well as their pathname components) are
>>transparently encrypted and decrypted with the specified key without
>>further user intervention; cleartext is never stored on a disk or sent
>>to a remote file server.  CFS employs a novel combination of DES
>>stream and codebook cipher modes to provide high security with good
>>performance on a modern workstation.  CFS can use any available file
>>system for its underlying storage without modification, including
>>remote file servers such as NFS.  System management functions, such as
>>file backup, work in a normal manner and without knowledge of the key.
>
>What happens to hard links?
>
>mkdir foo bar
>CFS_set_directory_key -directory ./foo -key foo-key
>CFS_set_directory_key -directory ./bar -key bar-key
>cp /etc/passwd ./foo/test1
>ln ./foo/footest ./bar/bartest
>cmp ./foo/footest ./bar/bartest

This is a serious flaw. The emperor has no clothes. People should
sue at&t for this shit.

From nobody at c2.org  Sat Oct 28 14:50:18 1995
From: nobody at c2.org (Anonymous User)
Date: Sun, 29 Oct 1995 05:50:18 +0800
Subject: CJR returned to sender
Message-ID: <199510282012.NAA25772@infinity.c2.org>

In article <>
bal at martigny.ai.mit.edu wrote:
>   Date: Wed, 25 Oct 1995 09:08:15 -0700
>   X-Sender: tcmay at mail.got.net
>   Mime-Version: 1.0
>   Content-Type: text/plain; charset="us-ascii"
>   From: tcmay at got.net (Timothy C. May)
>   Sender: owner-cypherpunks at toad.com
>   Precedence: bulk
>
>   At 6:35 AM 10/25/95, Timothy C. May wrote:
>   >
>   >(* Hal Abelson of MIT says there are possible export problems with the MIT
>   >Press book on PGP, and MIT dropped plans for a version in a special OCR
>   >font. So, I agree that _some_ books cross the line and look like pure
>   >software. However, I continue to maintain that a badly-printed barcode is
>   >just a joke, nothing more.)
>
>   Brian LaMacchia sent me e-mail saying the MIT book _was_ published with the
>   OCR font as originally planned. No response to their CJR request, submitted
>   in Jan or Feb.
>
>[Blatant plug for MIT Press...]
>
>For reference, the title of the book is "PGP: Source Code and
>Internals", ISBN 0-262-24039-4, hardcover, $60.00.  There are links to
>the MIT Press pages from my keyserver home page
(http://www-swiss.ai.mit.edu/~bal/keyserver.html), or you can go to MIT
>Press's site (http://www-mitpress.mit.edu/) and look under
>Books/Computer Science.  Orders accepted over the net using either HTML
>forms (SSL) or e-mail (PGP).
>
>MIT Press is also selling "MIT PGP" T-Shirts, but I don't have pricing
>or size information on them yet.  They have the logo from the book cover
>on the front & back.  Front says "Mind your own business," back has a
>copy of MIT Press's PGP public key (in ASCII-armored form).
>
>					--bal

Its worth 60 buckx because the book has the old version without the
weakness in it. they are probably assuming that people will look at the
book instead of the ftp source code and then get lazy and complie the
code off the ftp instead of typing or scanning the book.

From bal at martigny.ai.mit.edu  Sat Oct 28 15:11:06 1995
From: bal at martigny.ai.mit.edu (Brian A. LaMacchia)
Date: Sun, 29 Oct 1995 06:11:06 +0800
Subject: CJR returned to sender
In-Reply-To: <199510282012.NAA25772@infinity.c2.org>
Message-ID: <9510282131.AA11388@toad.com>

   Date: Sat, 28 Oct 1995 13:12:08 -0700 (PDT)
   X-Authentication-Warning: infinity.c2.org: remail set sender to nobody using -f
   From: Anonymous User 
   Complaints-To: remailer-owner 
   Sender: owner-cypherpunks at toad.com
   Precedence: bulk

   >For reference, the title of the book is "PGP: Source Code and
   >Internals", ISBN 0-262-24039-4, hardcover, $60.00.  There are links to
   >the MIT Press pages from my keyserver home page
   (http://www-swiss.ai.mit.edu/~bal/keyserver.html), or you can go to MIT
   >Press's site (http://www-mitpress.mit.edu/) and look under
   >Books/Computer Science.  Orders accepted over the net using either HTML
   >forms (SSL) or e-mail (PGP).

   Its worth 60 buckx because the book has the old version without the
   weakness in it. they are probably assuming that people will look at the
   book instead of the ftp source code and then get lazy and complie the
   code off the ftp instead of typing or scanning the book.

This is blatently false and an obvious troll.  The book contains a copy
of the source code for MIT PGP 2.6.2, the same version currently being
distributed by MIT.

					--bal

From mab at crypto.com  Sat Oct 28 17:07:10 1995
From: mab at crypto.com (Matt Blaze)
Date: Sun, 29 Oct 1995 08:07:10 +0800
Subject: New release of CFS Unix encrypting file system available
In-Reply-To: <199510282012.NAA25761@infinity.c2.org>
Message-ID: <199510282357.XAA09892@crypto.com>

Anonymous writes:
> >
> >What happens to hard links?
> >
> >mkdir foo bar
> >CFS_set_directory_key -directory ./foo -key foo-key
> >CFS_set_directory_key -directory ./bar -key bar-key
> >cp /etc/passwd ./foo/test1
> >ln ./foo/footest ./bar/bartest
> >cmp ./foo/footest ./bar/bartest
> 
> This is a serious flaw. The emperor has no clothes. People should
> sue at&t for this shit.

I'm not sure why I'm bothering to respond to this, but I'd hate to
think someone might take the above message seriously and think that
there's some kind of "serious flaw" in CFS demonstrated by this sequence
of (hypothetical, incorrect) commands.  So here goes:

What on earth are you talking about?

As I pointed out in a previous message, that's not how CFS works - you
can't link across encrypted directories.

There may be (and probably are) bugs in or attacks against CFS, but this
isn't one of them.

-matt

From daw at quito.CS.Berkeley.EDU  Sat Oct 28 17:36:02 1995
From: daw at quito.CS.Berkeley.EDU (David A Wagner)
Date: Sun, 29 Oct 1995 08:36:02 +0800
Subject: MD4-derived hash functions
Message-ID: <199510290023.UAA12614@book.hks.net>

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

In article <9510261603.AA26221 at zorch.w3.org>,   wrote:
> 
> 3DES with only two independent keys is only slightly more secure than
> DES, consider a variant of the meet in the middle attack exploiting 
> the fact that the constraint network is reductible to two equations
> in one unknown.
> 

Huh?  Are you sure you're not thinking of 2DES?

2DES is known to be not much more secure than DES: 2DES can be broken
with 2^56 operations and 2^56 space.  (The space requirements can be
eliminated without too much extra cost in time.)

Could you post a reference for your claim that 2-key 3DES is insecure?
Or post an attack?  Or anything?
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

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

iQBFAwUBMJLJdSoZzwIn1bdtAQFFRQGAgPceMs6vYCq4nGQQ5QT9tOLIgiGAoY8M
B71KIQDP75TMiF1rgvorSWQsNZjzjhbm
=3bH5
-----END PGP SIGNATURE-----

From daw at quito.CS.Berkeley.EDU  Sat Oct 28 17:46:40 1995
From: daw at quito.CS.Berkeley.EDU (David A Wagner)
Date: Sun, 29 Oct 1995 08:46:40 +0800
Subject: MD4-derived hash functions
In-Reply-To: <199510270413.VAA29718@ix7.ix.netcom.com>
Message-ID: <199510290028.UAA12628@book.hks.net>

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

In article <199510270413.VAA29718 at ix7.ix.netcom.com>,
John Lull  wrote:
> 
> Even for 2DES, or for 3-key 3DES, doesn't a meet in the middle attack
> require on the order of 2^56 words of memory?
> 

Actually, as it turns out, van Oorschot & Wiener have a recent paper
which describes how to break 2DES without the huge space requirements
without sacrificing too much time (by using their parallel collision
search method).  They estimated the cost to break 2DES via specialized
hardware, and decided that breaking 2DES was only about 2^14 times as
costly as breaking DES.

The conclusion to take away from this is simple: double encryption
doesn't give you much extra security over single encryption.  Don't
use double encryption.
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

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

iQBFAwUBMJLKmSoZzwIn1bdtAQEk5gF/VtAgBNgB6o8SrTWSSMaciikdzoVCIqYF
JdXxs4pWt6ueY8WVsSEj5yU5EKAT0/4M
=6YNF
-----END PGP SIGNATURE-----

From daw at quito.CS.Berkeley.EDU  Sat Oct 28 17:57:10 1995
From: daw at quito.CS.Berkeley.EDU (David A Wagner)
Date: Sun, 29 Oct 1995 08:57:10 +0800
Subject: newsweek oct 30 Levy digital cash article
Message-ID: <199510290031.UAA12653@book.hks.net>

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

In article <199510272049.NAA29753 at netcom7.netcom.com>,
Vladimir Z. Nuri  wrote:
> 
> if this is true, I wanted to point out in my post that this is a property
> that real cash does not have. you cannot ever say to your bank from which
> you withdrew cash, "oops, I lost a piece, could you replace it? also, if
> someone spends the piece that I lost, tell them they can't?"
       [...]
> or, the bank might say, "oh, well, that cash was not spent yet. we can issue
> a replacement and bar the cash from being spent". this idea of "replacing"
> cash is of course unique to the electronic realm. if the bank does it,
> the consumer would be required to notify the bank before the cash is 
> spent, again another unusual property unique to e-cash.
> 

Hrmm, is this really unique to e-cash?  It sounds pretty similar to
traveller's checks.

(I do like your suggestion that e-cash service providers should write
a FAQ listing all the properties of their ``cash''!)
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

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

iQBFAwUBMJLLRCoZzwIn1bdtAQE2cwGAzWzY/2tqwjLpMSEr210r607j5mxUskJT
3L8qyQOCTMLjrZWfAwmQZ28yAszojBm+
=23AU
-----END PGP SIGNATURE-----

From jamesd at echeque.com  Sun Oct 29 10:27:58 1995
From: jamesd at echeque.com (James A. Donald)
Date: Sun, 29 Oct 95 10:27:58 PST
Subject: Digicash will not fly
Message-ID: <199510291827.KAA07985@blob.best.net>

While Chaum is a brilliant cryptographer, he is an incompetent businessman

He has demonstrated this in numerous ways.

The latest being "Cash" where the bank skims off 4% to 10% every time.

No one is going to use digicash under these kinds of terms and 
conditions.
 ---------------------------------------------------------------------
              				|  
We have the right to defend ourselves	|   http://www.jim.com/jamesd/
and our property, because of the kind	|  
of animals that we are. True law	|   James A. Donald
derives from this right, not from the	|  
arbitrary power of the state.		|   jamesd at echeque.com

From scs at lokkur.dexter.mi.us  Sat Oct 28 19:53:48 1995
From: scs at lokkur.dexter.mi.us (Steve Simmons)
Date: Sun, 29 Oct 1995 10:53:48 +0800
Subject: New release of CFS Unix encrypting file system available
In-Reply-To: <199510282012.NAA25761@infinity.c2.org>
Message-ID: <46upi0$53c@lokkur.dexter.mi.us>

Anonymous User  writes:

>This is a serious flaw. The emperor has no clothes. People should
>sue at&t for this shit.

This is one of those times that I don't see much use for anonymity...
-- 
` . . . I'm a sysadmin, with an admitted preference for things I can
reboot over things I have to negotiate with . . . '
		Mike Shaver (shaver at neon.ingenia.com)

From khijol!erc at uunet.uu.net  Sat Oct 28 22:01:14 1995
From: khijol!erc at uunet.uu.net (Ed Carp [khijol SysAdmin])
Date: Sun, 29 Oct 1995 13:01:14 +0800
Subject: 1995-10-27 Members Named to Nat Security Telecom Committee (fwd)
Message-ID: 

---------- Forwarded message ----------
Date: Fri, 27 Oct 1995 20:11-0400
From: The White House 
To: Public-Distribution at clinton.ai.mit.edu
Subject: 1995-10-27 Members Named to Nat Security Telecom Committee

                            THE WHITE HOUSE

                     Office of the Press Secretary

________________________________________________________________________
For Immediate Release                                   October 27, 1995

	     PRESIDENT NAMES MEMBERS TO THE NATIONAL SECURITY 
	       TELECOMMUNICATIONS ADVISORY COMMITTEE (NSTAC) 

     President Clinton today announced his intent to appoint the following
individuals to the National Security Telecommunications Advisory Committee
(NSTAC):

     Dr. Vance D. Coffman is the president of Lockheed Martin Corporation.
Previously, he was president of the Space Systems Division of Lockheed
Missiles and Space Co. and vice president of the corporation.  Dr. Coffman
was responsible for the Hubble Space Telescope, MILSTAR, Follow-on Early
Warning, and the worldwide mobile commercial cellular phone system,
Iridium.  He holds a B.S. degree in aerospace engineering from Iowa State
University, and masters and doctoral degrees in aeronautics and
astronautics from Stanford University.

     Mr. Paul E. Wright is chairman of Chrysler Technologies Corporation
(CTC), the aerospace and defense electronics arm of the Chrysler
Corporation.  He was president and chief operating officer of Fairchild
Industries prior to joining CTC.  Mr. Wright guided the company's focus
toward spacecraft, defense electronics, and selected industrial products.
Mr. Wright spent 28 years with RCA Corporation, during which time he rose
to senior vice president.  He was responsible for developing and
administrating the strategic plans for RCA.
     Van B. Honeycutt is president of Computer Sciences Corporation (CSC),
the largest independent provider of information technology consulting,
systems integration, and outsourcing to industry and government.  He began
his career with CSC in 1975, serving as a regional marketing manager for
Infonet, the company's timesharing and value-added network, which CSC sold
in 1989.  In 1983, Mr. Honeycutt became president of CSC Credit Services.
He was later promoted to corporate vice president and president of CSC's
Industry Services Group in 1987.  He led CSC's advance into the growing
outsourcing market, negotiating the industry's largest outsourcing pact, a
10 year, $3 billion agreement with General Dynamics Corporation.

     The President's National Security Telecommunications Advisory
Committee (NSTAC) provides the President with information and advice from
the industry's perspective regarding specific measures to maintain,
protect, and enhance the nation's telecommunications resources that
support national security and emergency preparedness capabilities.  The
Committee addresses telecommunications issues throughout the year and
periodically reports directly to the President, and also to the Secretary
of Defense in his capacity as the Executive Agent for the National
Communications System.

-30-30-30-

From khijol!erc at cygnus.com  Sat Oct 28 22:09:29 1995
From: khijol!erc at cygnus.com (Ed Carp [khijol SysAdmin])
Date: Sun, 29 Oct 1995 13:09:29 +0800
Subject: Need Mail-to-News gates
In-Reply-To: 
Message-ID: 

On Fri, 27 Oct 1995, Alan Patterson wrote:

> On Fri, 27 Oct 1995 bluebird at alpha.c2.org wrote:
> 
> > Could someone PLEASE netmail me some _known reliable_ gates that use the
> > straight netmail address format (alt.whatnot at bosco.kollege.edu)?
> 
> If someone will direct me to sources, I'll try and setup a gate. (We use 
> INN).

Why not take the easy way out - set up an alias in /usr/lib/aliases to 
run inews on the incoming email?
--
Ed Carp, N7EKG    			Ed.Carp at linux.org, ecarp at netcom.com
					214/993-3935	voicemail/pager
Finger ecarp at netcom.com for PGP 2.5 public key		an88744 at anon.penet.fi

Q.	What's the trouble with writing an MS-DOS program to emulate Clinton?
A.	Figuring out what to do with the other 639K of memory.

From greg at ideath.goldenbear.com  Sun Oct 29 01:03:19 1995
From: greg at ideath.goldenbear.com (Greg Broiles)
Date: Sun, 29 Oct 1995 16:03:19 +0800
Subject: Conference in Eugene, OR - 11/3 and 11/4
Message-ID: <199510290728.AA06911@ideath.goldenbear.com>

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

One of the professors at the U of Oregon School of Law here in Eugene,
Keith Aoki, has put together what looks like a pretty good conference.
As far as I can tell, it's going to be something of a sleeper - lots of
good speakers, and probably not very many people in the audience who'll
be able to appreciate what they're seeing. Folks on the west coast 
interested in law and technology policy might do well to pop up to Eugene
for the weekend.

I've got limited floor space for people who need a place to crash and 
don't want to pony up the $ for a place in Eugene. (I'm in Springfield,
the redneck town across I-5 from Eugene - I'm about 15 mins from campus
by car, and can give folks a ride over if they're willing to stay for
the day.) Motel rooms ought to run between $30 and $80 per night in
Eugene, depending on whether or not knife marks on the headboard and the
smell of old cigarettes bothers you. :) 

Eugene is 2 hours (~ 110 miles) south of Portland on I-5 and 8 or 9
hours north of the Bay Area by car, up I-5. There's an airport here, so
it's possible to fly in - some rocket scientist planners put the airport
way north and west of anything interesting in town, though. 

The conference is Friday, November 3, and Saturday, November 4. Speakers
include (in no special order): 

John Perry Barlow
James Boyle
Rosemary Coombe
Steven Winter
Rudy Rucker
Tim Sloan
A. Michael Froomkin
Marc Rotenberg
Lee Tien
Cait Clarke
Gary Glisson
Rex Heinke
Eric Hughes
Matthew Ghourdjian
Benjamin Kaminash
Barry Schrader
Vibeke Sorenson
Dhruv Khann
Jerry Kang
Peter Jaszi
Jessica Litman
David Peterson
Brian Stine
Alfred Yen
Richard Stallman
James Love
Pamela Samuelson
Jerry Berman
Shari Steele
E. Wally Van Valkenburg
Margaret Chon

Folks who want to stay with me (you should be at least dog-tolerant)
or who want help getting picked up at the airport/finding a motel/whatever
are welcome to give me a call (503 744 2713) or send E-mail.

I think there's some charge to get in (not for law students, so I haven't
been especially attentive to it) but Keith said that we can probably waive
that if folks are interested and can't pay. If that sounds like a problem,
send mail, and I'll see if I can get him to issue some Cypherpunk passes.
(The idea is to extract $ from working attorneys without scaring away 
interested non-attorneys.) 

It ought to be quite a conference. By all means, if you can make it, 
come on up (or down). 

From jathomas at netcom.com  Sun Oct 29 19:22:45 1995
From: jathomas at netcom.com (John A. Thomas)
Date: Sun, 29 Oct 95 19:22:45 PST
Subject: EE Times on IDEA
In-Reply-To: 
Message-ID: 

On Mon, 30 Oct 1995, Eric Young wrote:

> On Sat, 28 Oct 1995, Anonymous wrote:
> > Electronic Engineering Times
> > Oct 23, 1995 p. 66
> > 
> > T.R MADHUSUDAN SASTRY,
> > T. GANESAN, B.MADHUKAR
> > AND N. SRINIVASA
> 
> > involved. The current implementation of Idea in ECB on Motorola's DSP
> > 56166 running at 60 Mhz supports up to 625 kbits/second in full-duplex
> > mode. That is 3.6 > times faster than using the DES algorithm. 
> 
> That last statement is rubbish.  For most CPU's I've seen, IDEA is either 
> the same speed as DES or a bit slower.  There is no way that it is 3 
> times faster that single DES.

My implementation of IDEA on the TI TMS320C26 DSP runs at 99 kbytes/sec.
I havent't tried DES, but comparing DES code on the 80x86 to the 'C26 
instruction set, I think the speeds would probably be about the same.

Whatever, these speeds leave plenty of time for simple speech coding in a 
voice encryption system.

---------------------------------------------------------------------
John A. Thomas          | (214) 263-4351   | jathomas at netcom.com
Bowles & Thomas, L.L.P. |      Voice       | CompuServe 75236,3536
410 N.W Eleventh St.    | (214) 262-6520   | 
Grand Prairie, Tx 75050 |       Fax        | PGP public key available
---------------------------------------------------------------------

From cme at TIS.COM  Sun Oct 29 06:58:26 1995
From: cme at TIS.COM (Carl Ellison)
Date: Sun, 29 Oct 1995 22:58:26 +0800
Subject: Human ID through insecure channel
Message-ID: <9510291444.AA24504@tis.com>

>Date: Mon, 16 Oct 1995 13:51:27 -0700
>From: Hal 
>Subject: Human ID through insecure channel
>
>Here is an example of the Matsumoto/Imai scheme for identifying yourself
>via a shared secret over an insecure channel, a system which is simple
>enough to be done in your head but which can withstand repeated
>observations by an adversary without being broken.

Hal,

	has this been written up someplace where I might read their
description?

	From your description of it, I have a way to break it in O(N)
samples, where N is the number of characters in the challenge string and
the factor of proportionality is strictly a function of how sure you want
to be that you have a correct break.

 - Carl

 +--------------------------------------------------------------------------+
 |Carl M. Ellison      cme at tis.com    http://www.clark.net/pub/cme          |
 |Trusted Information Systems, Inc.   http://www.tis.com/                   |
 |3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
 |Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
 +--------------------------------------------------------------------------+

From mhw at wittsend.com  Sun Oct 29 08:01:40 1995
From: mhw at wittsend.com (Michael H. Warfield)
Date: Mon, 30 Oct 1995 00:01:40 +0800
Subject: New release of CFS Unix encrypting file system available
In-Reply-To: <199510282357.XAA09892@crypto.com>
Message-ID: 

Matt Blaze enscribed thusly:
> 
> Anonymous writes:
> > >
> > >What happens to hard links?
> > >
> > >mkdir foo bar
> > >CFS_set_directory_key -directory ./foo -key foo-key
> > >CFS_set_directory_key -directory ./bar -key bar-key
> > >cp /etc/passwd ./foo/test1
> > >ln ./foo/footest ./bar/bartest
> > >cmp ./foo/footest ./bar/bartest
> > 
> > This is a serious flaw. The emperor has no clothes. People should
> > sue at&t for this shit.

	"Sue AT&T..."  For free, unsupported software?  In a remark's
from a coward hiding behind an anonymus remailer.  For a problem
that is all in his own mind!

	Give Me A Break!

> I'm not sure why I'm bothering to respond to this, but I'd hate to
> think someone might take the above message seriously and think that
> there's some kind of "serious flaw" in CFS demonstrated by this sequence
> of (hypothetical, incorrect) commands.  So here goes:

	Matt, you're responding to an annonymous twit spouting ignorant
ravings because if you didn't, some others would think this guy had something
significant to say.  It's a sad state of afairs when someone creates a
great package like CFS and then has to deal with an annoyance like this.

> What on earth are you talking about?

	You think he knows?  You give him a lot more credit than I would!

> As I pointed out in a previous message, that's not how CFS works - you
> can't link across encrypted directories.
> 
> There may be (and probably are) bugs in or attacks against CFS, but this
> isn't one of them.

	To quote one of Gary Trudeau's characters from "Doonsburry" -
"Look!  The clothes have no Empereror!"

> -matt

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

From prakriya at gradient.cis.upenn.edu  Sun Oct 29 09:01:22 1995
From: prakriya at gradient.cis.upenn.edu (Mahesh Prakriya)
Date: Mon, 30 Oct 1995 01:01:22 +0800
Subject: ques. regd. STT
Message-ID: <199510291631.LAA24817@gradient.cis.upenn.edu>

Hi. A group of us at the U. of Penn. are doing a presentation
on STT. I would like to know if you have any suggestions for us.

I've taken a look at the Visa & MS home pages and have a good
amount of information on STT. 

I'm esp. interested in finding out about the potential weaknesses
in STT. 

thanks,
Mahesh

+-----------------------------------------------------------------------+
Work					Home
-------					-----
1717 Arch St., 3E4			1801 JFK Blvd., #512
Phila., PA 19103			Phila., PA 19103
(215)-466-5476				(215)-567-2006

Internet:	prakriya at gradient.cis.upenn.edu
		http://www.cis.upenn.edu/~prakriya/home.html

PGP fingerprint =  6A EC 5B F3 D4 33 F6 D1  4C DA 99 11 F9 D9 89 A7
+-----------------------------------------------------------------------+

From buster at klaine.pp.fi  Sun Oct 29 09:06:22 1995
From: buster at klaine.pp.fi (Kari Laine)
Date: Mon, 30 Oct 1995 01:06:22 +0800
Subject: Hash collisions [was Re: MD5 weaknes
In-Reply-To: <1995Oct25.093455.1151.341098@smtpgate.cmp.com>
Message-ID: 

>I have unsubscribed from this mailing list. Please remove my name 
>from   
>your personal address lists. Thanks.
>ahg3

Sir,

your tactics to get rid of a mailing list 
is causing at least me and probably some
others a pain. To be a pain is not a 
right tactics to get rid of a list 
because you might be treated as a pain.
Hmm which would get you removed from
the list...

Anyway be nice to this person and
get rid of him.

Kari

From somogyi at digmedia.com  Sun Oct 29 11:53:13 1995
From: somogyi at digmedia.com (Stephan Somogyi)
Date: Mon, 30 Oct 1995 03:53:13 +0800
Subject: Austin E-Commerce Conf -- BOF?
Message-ID: 

If there are any other cypherpunks-readers attending the e-commerce
conference in Austin on Monday and Tuesday, it might be fun to get
together for an impromptu BOF either at lunchtime or later in the
evening.

Email me if there is interest.

_______________________________________________________________________
Stephan Somogyi               Senior Editor               Digital Media

From eay at mincom.oz.au  Sun Oct 29 14:53:53 1995
From: eay at mincom.oz.au (Eric Young)
Date: Mon, 30 Oct 1995 06:53:53 +0800
Subject: EE Times on IDEA
In-Reply-To: <199510281250.NAA14958@utopia.hacktic.nl>
Message-ID: 

On Sat, 28 Oct 1995, Anonymous wrote:
> Electronic Engineering Times
> Oct 23, 1995 p. 66
> 
> T.R MADHUSUDAN SASTRY,
> T. GANESAN, B.MADHUKAR
> AND N. SRINIVASA

> involved. The current implementation of Idea in ECB on Motorola's DSP
> 56166 running at 60 Mhz supports up to 625 kbits/second in full-duplex
> mode. That is 3.6 > times faster than using the DES algorithm. 

That last statement is rubbish.  For most CPU's I've seen, IDEA is either 
the same speed as DES or a bit slower.  There is no way that it is 3 
times faster that single DES.

		DES cbc		IDEA cbc
DSP 56166	 ???		  78 k/s	(625 kbits/sec)
486DX/50	 274 k/s	 177 k/s 	Solaris 2.4
Pentium 90	 703 k/s	 605 k/s	Linux
'old' R6000 box  295 k/s	 283 k/s
'old' Alpha box	1300 k/s	 690 k/s	(no 64 bit optimisations)
88100		 558 k/s	 526 k/s
PA-RISC		1072 k/s	 616 k/s	(very compiler dependant)
R4400 200mhz	1600 k/s	1290 k/s
Sparc 10	 695 k/s	 679 k/s

All speeds are in bytes/second.  The DES implementation is a 'standard'
fast DES (there are at least 2 DES packages on the net with this type of
speed) and the IDEA implementation is a 'standard' IDEA implementation
(similar speed to the reference versions) Both written in C.  I have
looked at how I could optimise IDEA but it does not lend it's self to vast
improvements the way DES does.  It may be possible to speed up IDEA by
%20 with good C compilers but that will still only be the speed of DES, I
do not think IDEA should be 'sold' as being faster than DES is software. 
It is not.  It has over twice the key length (128 vs 56) and that is it's
main benefit.

eric (having a rant at mis-information).
--
Eric Young                  | Signature removed since it was generating
AARNet: eay at mincom.oz.au    | more followups than the message contents :-)

From stewarts at ix.netcom.com  Sun Oct 29 15:24:03 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Mon, 30 Oct 1995 07:24:03 +0800
Subject: CJR returned to sender
Message-ID: <199510292300.PAA22971@ix11.ix.netcom.com>

At 10:10 AM 10/27/95 -0400, "Josh M. Osborne"  wrote:
> They may help spread the word about
>how foolish the ITAR is, and that is their only real value (well
>aside from entertainment).

US News & World Report, October 16, 1995, page 28, has a short
article on the shirt in their Washington Whispers column :-)
It's not totally accurate, but it talks about how the Feds oppose
export of "simple but powerful computer programs that can be used
to encrypt electronic communications.  Computer buffs and private
security experts say such restrictions are a threat to privacy -
as well as an absurd anachronism, since the programs are already
widely available.  To underscore the point, one disgruntled citizen
is now offering for sale over the Internet (http://colossus.net/
wepinsto/wshome.html) a T-shirt emblazoned with an encryption program
known as RSA" and a bit more about the shirt and issues
(and Don's refund offer to anyone arrested for wearing it)

>However I think it is a good idea to slowly approch the dividing
>line between exportable and non-exportable.  Wouldn't it be nice
>to be able to hold up the shirt and say "this is exportable", and
>then scan it & save it onto a floppy and then say "this is not"
>(assuming that a floppy of the shirt is denyed CJ) when arguing
>with someone about how arbatary the export laws are?

Obviously the next revision of the shirt should have a pocket for
the optional non-exportable floppy disk :-)
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From stewarts at ix.netcom.com  Sun Oct 29 15:24:14 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Mon, 30 Oct 1995 07:24:14 +0800
Subject: Don't Kill the Messenger--A New Slant on Remailers
Message-ID: <199510292300.PAA22989@ix11.ix.netcom.com>

At 07:45 PM 10/20/95 +0100, "Rev. Mark Grant"  wrote:
>> "You have a piece of mail awaiting at our mail delivery service. The
>> originator is unknown. The title of the message is "Tentacles of Medusa
>> Must Die!" You may retrieve this message by replying to this notification
>> with the word "Yes" anywhere in the Subject field. This message will be
>> kept for 60 days and then deleted."
>
>I suspect that I could easily hack this into Mixmaster in a day or two,
>but wouldn't it open you to attacks where Anonymous Fed, say, sends
>terrorist kiddy-porn through your remailer and busts your ISP during those
>60 days for possession ? I'm not sure if it would be better or worse than
>current setups from that point of view. 

One way to deflect this attack is to encrypt the message for storage
using a symmetric-key algorithm with a randomly generated session key,
and send the session key to the recipient with the notification.
You still have 300 MB of planted kiddy-terrorist narcopornography on your
machine,
but it's encrypted and you can happily tell the judge that you _can't_
decrypt it because you don't have the key.  The Feds _could_ get the
keys by eavesdropping on your outgoing correspondence or using
your system to send the material to themselves (or a conveniently employed
child), but at least you're not storing it in plaintext.

More of a problem with this system is that it's only useful for terminal
remailers; to use it in the middle of a chain, the next remailer would
need to be configured to auto-accept such messages, or else your remailer
would need to have a list of known remailers and use direct delivery
for all mail sent to them.
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From zeus at pinsight.com  Sun Oct 29 15:46:31 1995
From: zeus at pinsight.com (J. Kent Hastings)
Date: Mon, 30 Oct 1995 07:46:31 +0800
Subject: Quebec Libre
Message-ID: <199510292336.PAA31401@chico.pinsight.com>

-- [ From: J. Kent Hastings * EMC.Ver #2.5.02 ] --

Cpunx, especially offshore banking "fonts of wisdom,"

A friend asks:

> Concerning Quebec Libre, I would love to establish residence there before
the
> separation (not necessarily physical residence). Have these fonts of
wisdom
> on St. Louis and Anguilla banking anything on getting Quebec residency,
mail
> services, and bank accounts?

Any plans if Quebec secedes?

Kent
--
"Put pages for your business on the World Wide Web,  just $5 per month!" --
J. Kent Hastings --  zeus at pinsight.com -- http://www.pinsight.com/~zeus/

From stewarts at ix.netcom.com  Sun Oct 29 16:48:02 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Mon, 30 Oct 1995 08:48:02 +0800
Subject: MD5 weakness ? [was Re: Netscape Logic Bomb detailed by IETF]
Message-ID: <199510300037.QAA08347@ix5.ix.netcom.com>

>>As to weaknesses, I seem to remember that someone managed to forge a
>>modification to a program used to observe networks on a Sun so that it
>>had the same MD5 checksum as the official trusted version.  But whether
>>this is real is not strictly the issue. 

There was a program that forged CRC checksums that came out a couple years back,
letting you create a Trojan Horse and modify it to match Unix "sum" checksums
by adding junk to the end.  I'd be extremely surprised if anyone did this
with MD5;
CRCs are invertable, and generally short enough to brute-force as well.
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From s1113645 at tesla.cc.uottawa.ca  Sun Oct 29 17:19:02 1995
From: s1113645 at tesla.cc.uottawa.ca (s1113645 at tesla.cc.uottawa.ca)
Date: Mon, 30 Oct 1995 09:19:02 +0800
Subject: [noise] Re: Quebec Libre
In-Reply-To: <199510292336.PAA31401@chico.pinsight.com>
Message-ID: 

On Sun, 29 Oct 1995, J. Kent Hastings wrote:

> -- [ From: J. Kent Hastings * EMC.Ver #2.5.02 ] --
> 
> Cpunx, especially offshore banking "fonts of wisdom,"
> A friend asks:
> > Concerning Quebec Libre, I would love to establish residence there before
> the
> > separation (not necessarily physical residence). Have these fonts of
> wisdom
> > on St. Louis and Anguilla banking anything on getting Quebec residency,
> mail
> > services, and bank accounts?
> 
> Any plans if Quebec secedes?
Canada has a tax treaty with the States. Quebec wants to US permission 
to stay within NAFTA (and the States have already stated this will not be 
automatic). Similarly the PQ also wants to stay within other Canadian 
international treaties. 

I really don't see a separate Quebec becoming even a semblance of a tax 
haven or being  a hint less friendly to US interests than it is now.
We also have very high tax rates (and a bigger debt per cap) up here, 
Quebec's being the worst of all. I do remind you that Canada (french or 
english) is practically a political extension of the States. 

From msprague at owens.ridgecrest.ca.us  Sun Oct 29 18:51:10 1995
From: msprague at owens.ridgecrest.ca.us (M. F. Pat Sprague)
Date: Mon, 30 Oct 1995 10:51:10 +0800
Subject: S. 1284 To Amend (C) Act
Message-ID: <199510300240.SAA07345@owens.ridgecrest.ca.us>

"Tom Bell" The 9/28/95 Congression Report states that Senators Hatch and Leahy 
>have introduced a bill to amend the Copyright Act in accord with the 
>suggestions of the recent White Paper on the National Information 
>Infrastructure.  In relevant part, S. 1284:  1) makes transmission of copies a 
>type of publication (and thus potentially a means of infringing a 
>copyright); and 2) prohibits the importation, manufacture, or 
>distribution of any device the primary purpose of which is to 
>deactivate any technological protections that prevent or inhibit the 
>violation of copyrights.

What occurs to me is that PGP could be considered a "device" to obscure contents of data therby preventing the determination of a copyright violation.

(delitia)

>
>Tom W. Bell
>Assistant Professor 
>Law and Technology Program
>UD Law School
>bell at odo.law.udayton.edu
>
>PGP fingerprint:
>78 06 76 AC 32 38 A6 4C  B3 81 F4 1E 2E 27 AC 71
>
>
>

From ic58 at jove.acs.unt.edu  Sun Oct 29 20:15:16 1995
From: ic58 at jove.acs.unt.edu (Childers James)
Date: Mon, 30 Oct 1995 12:15:16 +0800
Subject: MD4-derived hash functions
In-Reply-To: <199510300353.AA55657@junkers.lochard.com.au>
Message-ID: 

On Mon, 30 Oct 1995, Mark wrote:

> >The conclusion to take away from this is simple: double encryption
> >doesn't give you much extra security over single encryption.  Don't
> >use double encryption.
> 
> That doesnt make sense. If one accepts that double encryption is securer than
> single encryption, wether marginally or twice as secure, why not use it?

Ah yes, but the vagarities of crypto don't lend themselves to real-world 
analogies so easily. With crypto schemes, if you use double-encryption, 
you effectively halve the amount of time needed to crack them. This is 
because of the "man in the middle attack." Schneier talks about it in 
Applied Crypto, and I am sure others on this list know the technical 
details better than I.

What Schneier says has been proven to be secure is, instead, a triple 
encryption scheme. Using two different keys, it goes something like this 
(if memory serves):

	Cipertext = P1xorEK1 -> C1xorDK1 -> C2xorEK1

Where P1 is the plaintext, EK1 is encrypt key 1, and DK1 is decrypt key 1.

That doesn't look right the longer I consider it, but the basic idea is 
there. Encrypt, decrypt, then encrypt again.

"Freedom is meaningless unless  | ic58 at jove.acs.unt.edu - James Childers
 you can give to those with whom| No man's freedom is safe
 you disagree." - Jefferson     |    while Congress is in session
        EA 73 53 12 4E 08 27 6C   21 64 28 51 92 0E 7C F7

From jya at pipeline.com  Sun Oct 29 20:41:05 1995
From: jya at pipeline.com (John Young)
Date: Mon, 30 Oct 1995 12:41:05 +0800
Subject: QUF_jpg
Message-ID: <199510300430.XAA01209@pipe3.nyc.pipeline.com>

   We have scanned "Quantum Computation's" seven formulae 
   and six figures as JPEG graphics files and will send for a 
plea:

   quf1.jpg -- Formulae 1-7; 32 kb.
   quf2.jpg -- Figures 1 and 2; 72 kb.
   quf3.jpg -- Figures 3 and 4; 95 kb.
   quf4.jpg -- Figures 5 and 6; 72 kb.

   Or, we will mash'em up .TIF, .PCX, .GIF, or tire-smeared
   pigeon.

   QUF_jpg  (4-part package, or items selected)

   [or *_tif, *_pcx, *_gif, *_tsp]

From jirib at sweeney.cs.monash.edu.au  Sun Oct 29 21:05:32 1995
From: jirib at sweeney.cs.monash.edu.au (Jiri Baum)
Date: Mon, 30 Oct 1995 13:05:32 +0800
Subject: newsweek oct 30 Levy digital cash article
In-Reply-To: <199510272049.NAA29753@netcom7.netcom.com>
Message-ID: <199510300447.PAA19230@sweeney.cs.monash.edu.au>

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

Hello Steven Levy 
  and cypherpunks at toad.com
  and "Vladimir Z. Nuri" 

V.Z.N (order of paragraphs rearranged by J.B.):
...
> I would suggest to all companies developing e-cash that they print up
> a carefully designed FAQ in which their cash properties 
> are compared directly with parallel
> properties of credit cards such as like the item above, because the
...

Well, why not one of us?

Please have a look at http://www.cs.monash.edu.au/~jirib/ecash-cc.html
and tell me what you think. Any good?

...
> how would the bank handle a situation in which the consumer says, "oops,
> my hard drive was compromised. all of the following cash was NOT spent
> by me."
...

Easy: whoever is at the bank first gets the cash. So you simply spend
all the coins (ie deposit it back to your account), and that's that.

...
> or, the bank might say, "oh, well, that cash was not spent yet. we can issue
> a replacement and bar the cash from being spent".
...

Yup. No special protocol is needed, either.

...
> S.L.:
> >Question: will people's worries about losing their e-money lead them to 
> >accept a higher degree of tracibility as a tradeoff?  
...

I read in the newspaper that the "Eros Foundation" (or whatever the name
is) has the second-largest mailing list in Australia. (The article was
about how they could affect elections should one or the other party promise
to ban X (non-violent erotica), and generally concluded that they could,
if they haven't already.) I wonder if that'd be a good market for
untraceable transactions?

Please tell me what you think of the page...
http://www.cs.monash.edu.au/~jirib/ecash-cc.html

Jiri
- --
If you want an answer, please mail to .
On sweeney, I may delete without reading!
PGP 463A14D5 (but it's at home so it'll take a day or two)
PGP EF0607F9 (but it's at uni so don't rely on it too much)

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

iQCVAwUBMJRYwCxV6mvvBgf5AQH+0QQAsAldRTy6AfXNB5f3+Edgr/Bsww+9gIdX
ZTwpWucd4yZof133m5p/qtKeu9KO2qrjBUBQB1W8L35i2O74+FLK2QX5BMftPCU0
F3ClojnayS8J7JZ6gJ42l8uKYglefQ/EnooEHVGO7RTF4t2gaIlstcm0QkdzPQzH
DbHjxVc+XvM=
=2wPg
-----END PGP SIGNATURE-----

From mark at lochard.com.au  Sun Oct 29 21:32:14 1995
From: mark at lochard.com.au (Mark)
Date: Mon, 30 Oct 1995 13:32:14 +0800
Subject: MD4-derived hash functions
In-Reply-To: <199510290028.UAA12628@book.hks.net>
Message-ID: <199510300353.AA55657@junkers.lochard.com.au>

>The conclusion to take away from this is simple: double encryption
>doesn't give you much extra security over single encryption.  Don't
>use double encryption.

That doesnt make sense. If one accepts that double encryption is securer than
single encryption, wether marginally or twice as secure, why not use it?

I would rather stand behind a steel door and a wooden door than a steel door
alone if anyone was shooting rounds at me.

Cheers,
Mark
mark at lochard.com.au

From ses at tipper.oit.unc.edu  Sun Oct 29 21:36:15 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Mon, 30 Oct 1995 13:36:15 +0800
Subject: MD4-derived hash functions
In-Reply-To: <199510300353.AA55657@junkers.lochard.com.au>
Message-ID: 

On Mon, 30 Oct 1995, Mark wrote:

> 
> That doesnt make sense. If one accepts that double encryption is securer than
> single encryption, wether marginally or twice as secure, why not use it?
> 

Hi Mark -

The problem with double encryption with DES is that it's vulnerable to a 
meet-in-the-middle attack if you have known plain text. You can encrypt 
the plaintext with all possible keys and store them in a (big) table, then 
decrypt the cypher text until you get a match with one of the values in 
the table. 

Doesn't work too well on an 8Mb P90 (2^59 bytes is half a peta byte), but 
since memory capacity theoretically increases as the square of processor 
speed, the attack becomes feasible much, much, sooner than breaking a 112 
byte key.

Using 3-DES,even with only two distinct keys, makes this attack 
infeasible, as the table size becomes much to large. 2-IDEA is similarly 
safe (2^131 bytes of memory is a long way off (I wonder what the first 
version of M$ Word to need that much memory will be).

Simon
 ---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 
	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From msprague at owens.ridgecrest.ca.us  Sun Oct 29 21:55:46 1995
From: msprague at owens.ridgecrest.ca.us (M. F. Pat Sprague)
Date: Mon, 30 Oct 1995 13:55:46 +0800
Subject: Digicash will not fly (not)
Message-ID: <199510300544.VAA12448@owens.ridgecrest.ca.us>

"James A. Donald" While Chaum is a brilliant cryptographer, he is an incompetent businessman
>
>He has demonstrated this in numerous ways.
>
>The latest being "Cash" where the bank skims off 4% to 10% every time.
>
>No one is going to use digicash under these kinds of terms and 
>conditions.

Doesn't just about everyone do precisely this when they pay sales tax?
Every time a buck arrives or departs a hand one pays a tax yet the system (you and I)continues accepting these terms albeit painfully.

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

From ses at tipper.oit.unc.edu  Sun Oct 29 21:58:59 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Mon, 30 Oct 1995 13:58:59 +0800
Subject: Important Digital Cash Question...
In-Reply-To: <199510300447.PAA19230@sweeney.cs.monash.edu.au>
Message-ID: 

Ok. So we've got Alice and Bob trading their cash back and forth, with 
Mallet trying to steal their cyber-dosh, and Eve listening to their 
conversations- this leads me to the big question:

What's the right name to use for the Banker? I've been using "Nick", 
after Nick Leeson; any other suggestions?

Simon 
---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From unicorn at polaris.mindport.net  Sun Oct 29 23:28:29 1995
From: unicorn at polaris.mindport.net (Black Unicorn)
Date: Mon, 30 Oct 1995 15:28:29 +0800
Subject: Digicash will not fly (not)
In-Reply-To: <199510300544.VAA12448@owens.ridgecrest.ca.us>
Message-ID: 

On Sun, 29 Oct 1995, M. F. (Pat) Sprague wrote:

> "James A. Donald"  >While Chaum is a brilliant cryptographer, he is an incompetent businessman
> >
> >He has demonstrated this in numerous ways.
> >
> >The latest being "Cash" where the bank skims off 4% to 10% every time.
> >
> >No one is going to use digicash under these kinds of terms and 
> >conditions.
> 
> 
> Doesn't just about everyone do precisely this when they pay sales tax?
> Every time a buck arrives or departs a hand one pays a tax yet the system (you and I)continues accepting these terms albeit painfully.

Unfortunately, now with digicash purchases you pay BOTH the sales tax AND 
the banks (extortionate) cut.

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

---
"In fact, had Bancroft not existed,       potestas scientiae in usu est
Franklin might have had to invent him."    in nihilum nil posse reverti
00B9289C28DC0E55  E16D5378B81E1C96 - Finger for Current Key Information

From tcmay at got.net  Sun Oct 29 23:30:30 1995
From: tcmay at got.net (Timothy C. May)
Date: Mon, 30 Oct 1995 15:30:30 +0800
Subject: Digicash will not fly (not)
Message-ID: 

At 5:41 AM 10/30/95, M. F. (Pat wrote:
>"James A. Donald" >While Chaum is a brilliant cryptographer, he is an incompetent businessman
>>
>>He has demonstrated this in numerous ways.
>>
>>The latest being "Cash" where the bank skims off 4% to 10% every time.
>>
>>No one is going to use digicash under these kinds of terms and
>>conditions.
>
>
>Doesn't just about everyone do precisely this when they pay sales tax?
>Every time a buck arrives or departs a hand one pays a tax yet the system
>(you and I)continues accepting these terms albeit painfully.

Many types of business dealings are exempt from sales tax, through
arrangements for resales.

I don't know if the "skims off 4% to 10% every time" point accurately
describes how the current Digicash model works, but certainly this will not
fly as a long term rate. So many monetary transactions happen in the course
of business that even a 4% fee _per transaction_ would rapidly wipe out
most of the value.

--Tim May

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay at got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."

From Ross.Anderson at cl.cam.ac.uk  Mon Oct 30 02:41:09 1995
From: Ross.Anderson at cl.cam.ac.uk (Ross Anderson)
Date: Mon, 30 Oct 1995 18:41:09 +0800
Subject: Cuban Security Conference
Message-ID: <"swan.cl.cam.:050770:951030102939"@cl.cam.ac.uk>

Mr Guevara of the Cuban embassy in London asked me to post
this announcement. Pass it on.

		        CALL FOR PAPERS

			INFORMATICS  96

		International Conference Center
		     Pabexpo, Havana, Cuba
			March 4-9, 1996

			   INCLUDING

	3rd Ibero-American Seminar on Protection against
    Computer Viruses and Security of Information Technologies

	*	Antivirus and protection software

	*	Security of information technologies, including
		-  diagnostic and security plans
		-  risk analysis, contingency and recovery plans
		-  technical aspects: identification and
		   authentication, cryptography, security models
		-  security organisation and management, security
		   policy, information sorting, training of users
		   and authentication
		-  security evaluation
		-  integration of security systems
		-  audit trail

	*	Experience

	Chairman of the organising committee: Jose Bidot Pelaez,
	    Chairman, National Committee for Data Protection

			      AND

	   1st International Seminar on Information Audit

	*	Information audit in business and financial
		management

	*	Information audit and current technology

	*	Tools for information audit

	*	Controls and risks in information systems

	*	Information audit for information systems

	Chairman of the organising committee: Fransisco Deiros,
	President, Information Audit Group, National Committee
	                    of Informatics

	Papers should be sent to the convention secretariat:

		Lic. Nancy Batard Najarro
		INFORMATICS 96 Executive Secretary
		Palacio de las Convenciones
		Apartado 16046, La Habana, Cuba

		Tel: +537 33-1466 / 20-6850
		Fax: +537 33-1657 / 33-1708

		Email: infor96 at cenisi.cu

From rah at shipwright.com  Mon Oct 30 03:29:46 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Mon, 30 Oct 1995 19:29:46 +0800
Subject: Important Digital Cash Question...
Message-ID: 

>What's the right name to use for the Banker? I've been using "Nick",
>after Nick Leeson; any other suggestions?

How about "Pip", J. Pierpont Morgan's childhood nickname. OK, OK, I'll sit
down now...

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah at shipwright.com)
Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
USA (617) 323-7923
"Reality is not optional." --Thomas Sowell
>>>>Phree Phil: Email: zldf at clark.net  http://www.netresponse.com/zldf <<<<<

From raph at CS.Berkeley.EDU  Mon Oct 30 07:06:55 1995
From: raph at CS.Berkeley.EDU (Raph Levien)
Date: Mon, 30 Oct 1995 23:06:55 +0800
Subject: List of reliable remailers
Message-ID: <199510301450.GAA23506@kiwi.cs.berkeley.edu>

   I operate a remailer pinging service which collects detailed
information about remailer features and reliability.

   To use it, just finger remailer-list at kiwi.cs.berkeley.edu

   There is also a Web version of the same information, 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, which is available at:
ftp://ftp.csua.berkeley.edu/pub/cypherpunks/premail/premail-0.33a.tar.gz

   For the PGP public keys of the remailers, finger
pgpkeys at 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 at kiwi.cs.berkeley.edu.

$remailer{"extropia"} = " cpunk pgp special";
$remailer{"portal"} = " cpunk pgp hash";
$remailer{"alumni"} = " cpunk pgp hash";
$remailer{"bsu-cs"} = " cpunk hash ksub";
$remailer{"c2"} = " eric pgp hash reord";
$remailer{"penet"} = " penet post";
$remailer{"ideath"} = " cpunk hash ksub reord";
$remailer{"hacktic"} = " cpunk mix pgp hash latent cut post ek";
$remailer{"flame"} = " cpunk mix pgp. hash latent cut post ek reord";
$remailer{"rahul"} = " cpunk pgp hash filter";
$remailer{"mix"} = " cpunk mix pgp hash latent cut ek ksub reord";
$remailer{"syrinx"} = " cpunk pgp hash cut reord mix post";
$remailer{"ford"} = " cpunk pgp hash ksub";
$remailer{"hroller"} = " cpunk pgp hash mix cut ek";
$remailer{"vishnu"} = " cpunk mix pgp. hash latent cut ek ksub reord";
$remailer{"robo"} = " cpunk hash mix";
$remailer{"replay"} = " cpunk mix pgp hash latent cut post ek";
$remailer{"spook"} = " cpunk mix pgp hash latent cut ek reord";
$remailer{"rmadillo"} = " mix cpunk pgp hash latent cut";
$remailer{"ncognito"} = " cpunk";
$remailer{"precip"} = " cpunk mix pgp hash latent cut ek reord";
$remailer{"ecafe"} = " cpunk mix";
$remailer{"wmono"} = " cpunk mix pgp. hash latent cut ek";
catalyst at netcom.com is _not_ a remailer.
lmccarth at ducie.cs.umass.edu is _not_ a remailer.
usura at replay.com is _not_ a remailer.

Use "premail -getkeys pgpkeys at kiwi.cs.berkeley.edu" to get PGP keys
for the remailers. Fingering this address works too.

remailer  email address                        history  latency  uptime
-----------------------------------------------------------------------
ideath   remailer at ideath.goldenbear.com   -.-.-.---.-   7:12:57  99.97%
hacktic  remailer at utopia.hacktic.nl       ************     9:03  99.95%
rmadillo remailer at armadillo.com           ++++++++++++    42:02  99.93%
ecafe    remail at ecafe.org                 **####+*##*#     1:37  99.93%
wmono    wmono at valhalla.phoenix.net       ************    13:17  99.91%
penet    anon at anon.penet.fi               ---------+++  2:58:18  99.74%
robo     robo at c2.org                           ###--*#    25:08  99.71%
spook    remailer at valhalla.phoenix.net    ******** *+*    16:41  99.69%
replay   remailer at replay.com              *****+* * **     6:34  99.52%
mix      mixmaster at remail.obscura.com     ---- -- ---   1:44:59  99.46%
c2       remail at c2.org                    +    +++-- *    53:17  98.82%
syrinx   syrinx at c2.org                    -  _ ____ .+ 55:55:41  97.38%
bsu-cs   nowhere at bsu-cs.bsu.edu           ***  #  #-+#    24:49  97.23%
flame    remailer at flame.alias.net           *     **+*    24:32  92.21%
vishnu   mixmaster at vishnu.alias.net         *     +***    10:39  90.65%
rahul    homer at rahul.net                  ***#*+ +#***     2:53  99.79%
alumni   hal at alumni.caltech.edu           +++#**-*+#       7:27  86.61%
portal   hfinney at shell.portal.com         **##*#-###       5:38  86.60%
ford     remailer at bi-node.zerberus.de     ____.--      38:06:00  86.33%
extropia remail at extropia.wimsey.com       -    . - -    5:24:35  63.83%

   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

From gebis at ecn.purdue.edu  Mon Oct 30 07:32:06 1995
From: gebis at ecn.purdue.edu (Michael J Gebis)
Date: Mon, 30 Oct 1995 23:32:06 +0800
Subject: Digicash will not fly (not)
Message-ID: <199510301515.KAA13367@purcell.ecn.purdue.edu>

> >While Chaum is a brilliant cryptographer, he is an incompetent businessman
> >He has demonstrated this in numerous ways.
> >The latest being "Cash" where the bank skims off 4% to 10% every time.
> >No one is going to use digicash under these kinds of terms and 
> >conditions.

> Doesn't just about everyone do precisely this when they pay sales tax?
> Every time a buck arrives or departs a hand one pays a tax yet the
> system (you and I)continues accepting these terms albeit painfully.

Theoretically, when I pay sales tax I get something in return (better
roads, nicer schools, improved NSA wiretaping, and other government
services.)  With digicash, you're paying for the use of the money
itself.

What sort of charges do Visa/Mastercard impose upon merchants?  I
thought it was 3%; if so, I would suspect that this is the level of
"off-the-top" skim that the market will sustain, and DigiCash should
probably use a similar rate.

-- 
Mike Gebis  gebis at ecn.purdue.edu  Corporate Operating Systems Still Suck

From farber at central.cis.upenn.edu  Mon Oct 30 08:22:32 1995
From: farber at central.cis.upenn.edu (Dave Farber)
Date: Tue, 31 Oct 1995 00:22:32 +0800
Subject: Digicash will not fly (not)
Message-ID: <199510301552.KAA24406@linc.cis.upenn.edu>

>
>What sort of charges do Visa/Mastercard impose upon merchants?  I
>thought it was 3%; if so, I would suspect that this is the level of
>"off-the-top" skim that the market will sustain, and DigiCash should
>probably use a similar rate.
>
>-- 
>Mike Gebis  gebis at ecn.purdue.edu  Corporate Operating Systems Still Suck
>

Pricing is usally set so it includes the 3%. Cash prices are usually by
agreement the same as credit card. Will Digicash be an extra %age or will
the credit card agreements be changed Else it is 3% plus digicash for those
goods that offer the credit card option

From turner at TeleCheck.com  Mon Oct 30 08:32:16 1995
From: turner at TeleCheck.com (turner at TeleCheck.com)
Date: Tue, 31 Oct 1995 00:32:16 +0800
Subject: Pinkerton Risk Assessment & "Security 2000"
In-Reply-To: <9510300619.AA11035@pulm1.accessone.com>
Message-ID: <9510301612.AA15533@mercury.telecheck.com>

blancw at accessone.com said:
> They advertise their services as:

> "... the risk assessment tool for the 21st century. If you or other 
> members of  your company travel internationally, the Global Risk 
> Network  on MSN. is an  invaluable service, keeping you informed of 
> worldwide events, political  turmoil, global sensitive spots, and 
> more! Now you have direct online access to  a wealth of exclusive 
> Pinkerton information, all via your computer. You can  even order 
> hard copy reports or have customized research performed by Pinkerton  
> Risk Assessment  experts, simply type in your request. Tailored for 
> the  individual traveler, as well as the corporate executive, our 
> risk services give  you several options to know the security 
> situation anywhere."
> 

The Deptartment of State has the same information available on Compu$erv
and possibly the internet.

Perhaps more importantly, this information is also available for free
on the Internet.

	http://dosfan.lib.uic.edu/
	gopher://dosfan.lib.uic.edu/

From hallam at w3.org  Mon Oct 30 08:41:28 1995
From: hallam at w3.org (hallam at w3.org)
Date: Tue, 31 Oct 1995 00:41:28 +0800
Subject: Digicash will not fly (not)
In-Reply-To: <199510301515.KAA13367@purcell.ecn.purdue.edu>
Message-ID: <9510301620.AA30950@zorch.w3.org>

>What sort of charges do Visa/Mastercard impose upon merchants?  I
>thought it was 3%; if so, I would suspect that this is the level of
>"off-the-top" skim that the market will sustain, and DigiCash should
>probably use a similar rate.

Not quite 3% in that sense. The rate is varfiable 35 ce3nts plus 3%
being typical. The essential point is that this is insurance on the
deal. If the buyre does not pay their bill the money is still paid
to the merchant. If the goods are faulty the buyer may have recourse
against the card co (UK consumer credit act).

The charging structure of Digicash should be different however. Digicash
is like Mondex, it effectively gives the operator a signorage rights
which can be highly profitable in themselves. The cash in the Digicash 
scheme is earning interest for Mark Twain Bank.

Comment heard at the firm "It's time to make another backup of the 
Internet". :-) 

	Phill

From hallam at w3.org  Mon Oct 30 09:04:15 1995
From: hallam at w3.org (hallam at w3.org)
Date: Tue, 31 Oct 1995 01:04:15 +0800
Subject: Important Digital Cash Question...
In-Reply-To: 
Message-ID: <9510301637.AA21874@zorch.w3.org>

>What's the right name to use for the Banker? I've been using "Nick", 
>after Nick Leeson; any other suggestions?

Thats Lessen, not Leeson. As in "I will lessen the amount of money you
have on deposit".

Actually you should have names beginning with I and A for Issuer and 
Aquirer.. But that messes up Alice. 

I think that the bankers name should be Ethel however.

	Phill

From stewarts at ix.netcom.com  Mon Oct 30 10:00:12 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Tue, 31 Oct 1995 02:00:12 +0800
Subject: Cuban Security Conference
Message-ID: <199510301723.JAA22047@ix9.ix.netcom.com>

>		International Conference Center
>		     Pabexpo, Havana, Cuba
>			March 4-9, 1996
>	3rd Ibero-American Seminar on Protection against
>    Computer Viruses and Security of Information Technologies

I wonder if they'd be receptive to talks on private communications,
digicash, tax avoidance through digital technology, anarchy and
collapse of government power, etc. :-)   (Maybe they would;
Cuba's got to do something to get their economy out of the
post-Soviet-subsidy doldrums, and with the US preventing free
trade in sugar for them, maybe allowing capitalism will be their
only choice...)

For any Yankees interested in going, you generally need to be
a journalist of some sort to avoid the Trading With The Enemy Act
restrictions, but in cyberspace, that's easily arranged.
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From ses at tipper.oit.unc.edu  Mon Oct 30 10:04:26 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Tue, 31 Oct 1995 02:04:26 +0800
Subject: Digicash will not fly (not)
In-Reply-To: 
Message-ID: 

One point worth noting is that the 5% cut used to be a typical fee for 
credit-card transactions. However, that cut only happened once per 
purchace, whereas digicash may incur this fee many more times. 

When I daydreamed about setting up a digicash issuer, I was thinking on 
the lines of a 2% fee for converting real money into digicash, then 
refunding any excess beyond cost of operations at the end of the year. 

Converting from real money to digicash is the most risky part of 
operations, so reserves should be proportional to this. Since my fantasy 
bank has a policy of not paying interest on digicash accounts, and 
keeping all assets in cash on (at worst) overnight deposit, this keeps 
things really safe. BTW, since I've got an aunt who lives in St. Brelade, 
the bank is in St Helier, Jersey, which has the great advantage of being 
one of the few Tax Havens to be able to get the Archers on FM.

Simon

From joelm at eskimo.com  Mon Oct 30 10:08:18 1995
From: joelm at eskimo.com (Joel McNamara)
Date: Tue, 31 Oct 1995 02:08:18 +0800
Subject: Pinkerton Risk Assessment & "Security 2000"
Message-ID: <199510301653.IAA24958@mail.eskimo.com>

For even more, free information of this type, see the Counter-Terrorism page:

http://www.interlog.com/~vabiro/

An interesting collection of links and data...

Joel

From patrick at Verity.COM  Mon Oct 30 10:10:32 1995
From: patrick at Verity.COM (Patrick Horgan)
Date: Tue, 31 Oct 1995 02:10:32 +0800
Subject: I-D ACTION:draft-eastlake-cybercash-v08-01.txt
Message-ID: <9510301638.AA17683@cantina.verity.com>

----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 70

A Revised Internet-Draft is available from the on-line Internet-Drafts 
directories.                                                               

       Title     : CyberCash Credit Card Protocol Version 0.8              
       Author(s) : D. Eastlake, B. Boesch, S. Crocker, M. Yesil
       Filename  : draft-eastlake-cybercash-v08-01.txt
       Pages     : 55
       Date      : 10/27/1995

CyberCash is developing a general payments system for use over the 
Internet.  The structure and communications protocols of version 0.8 are 
described.  This version includes credit card payments only.  Additional 
capabilities are planned for future versions.                   

This document covers only the current CyberCash system which is one of 
the few operational systems in the rapidly evolving area of Internet 
payments.  CyberCash is committed to the further development of its system 
and to cooperation with the Internet Engineering Task Force and other 
standards organizations.                                                             

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-eastlake-cybercash-v08-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-eastlake-cybercash-v08-01.txt

Internet-Drafts directories are located at:	

     o  Africa                                   
        Address:  ftp.is.co.za (196.4.160.8)	

     o  Europe                                   
        Address:  nic.nordu.net (192.36.148.17)	
        Address:  ftp.nis.garr.it (192.12.192.10)

     o  Pacific Rim                              
        Address:  munnari.oz.au (128.250.1.21)	

     o  US East Coast                            
        Address:  ds.internic.net (198.49.45.10)	

     o  US West Coast                            
        Address:  ftp.isi.edu (128.9.0.32)  	

Internet-Drafts are also available by mail.	

Send a message to:  mailserv at ds.internic.net. In the body type: 
     "FILE /internet-drafts/draft-eastlake-cybercash-v08-01.txt".

NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

For questions, please mail to Internet-Drafts at cnri.reston.va.us.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

----- End Included Message -----

----------
X-Sun-Data-Type: Multipart
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 24

Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="mailserv at ds.internic.net"

Content-Type: text/plain
Content-ID: <19951027135555.I-D at CNRI.Reston.VA.US>

ENCODING mime
FILE /internet-drafts/draft-eastlake-cybercash-v08-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-eastlake-cybercash-v08-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <19951027135555.I-D at CNRI.Reston.VA.US>

--OtherAccess--
   _______________________________________________________________________
  /  These opinions are mine, and not Verity's (except by coincidence;).  \
 |                                                       (\                |
 |  Patrick J. Horgan         Verity Inc.                 \\    Have       |
 |  patrick at verity.com        1550 Plymouth Street         \\  _ Sword     | 
 |  Phone : (415)960-7600     Mountain View                 \\/    Will    | 
 |  FAX   : (415)960-7750     California 94303             _/\\     Travel | 
  \___________________________________________________________\)__________/

From rah at shipwright.com  Mon Oct 30 10:11:03 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Tue, 31 Oct 1995 02:11:03 +0800
Subject: Important Digital Cash Question...
Message-ID: 

>I think that the bankers name should be Ethel however.
>
>        Phill

Wait, wait! I have another one. I call digital cash bankers "underwriters",
because they're basically underwriting digital certificates, like an
underwriter in the capital markets does.

So, we need a "U" name...

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah at shipwright.com)
Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
USA (617) 323-7923
"Reality is not optional." --Thomas Sowell
>>>>Phree Phil: Email: zldf at clark.net  http://www.netresponse.com/zldf <<<<<

From futplex at pseudonym.com  Mon Oct 30 10:16:34 1995
From: futplex at pseudonym.com (Futplex)
Date: Tue, 31 Oct 1995 02:16:34 +0800
Subject: S. 1284 To Amend (C) Act
In-Reply-To: <199510300240.SAA07345@owens.ridgecrest.ca.us>
Message-ID: <199510301634.LAA10488@opine.cs.umass.edu>

Tom Bell writes:
> [S. 1284 would]:  1) make[] transmission of copies a 
> type of publication (and thus potentially a means of infringing a 
> copyright); and 2) prohibit[] the importation, manufacture, or 
> distribution of any device the primary purpose of which is to 
> deactivate any technological protections that prevent or inhibit the 
> violation of copyrights.

M. F. (Pat) Sprague writes:
# What occurs to me is that PGP could be considered a "device" to obscure 
# contents of data therby preventing the determination of a copyright 
# violation.

Encryption (as opposed to decryption) doesn't defeat any mechanisms that 
stop someone from violating a copyright. It can make the _detection_ 
harder, but not the _commission_. So I don't think that should be a concern.
(As usual, IANAL.)

Building upon Tom Bell's and cjs' observations, I suppose it could be argued
that encryption can be employed as a means of copyright protection. Hence
some decryption programs might be outlawed as devices intended to
"deactivate" copyright-protecting technology. 

I can't think of any c'punks projects so far that try to pierce security 
schemes meant to shield materials from copyright violations. Since many 
cypherpunks aren't inclined to preserve copyrights, they lack a motive for
ensuring the integrity of copyright protection methods. Cypherpunks launch
attempts to crack security systems in order ultimately to improve them, not 
for the sake of breaking them. I expect the alt.2600 crowd would be more
directly affected by S. 1284.

As a matter of principle, though, I don't think we should be amicable to a
bill like S. 1284. It's a bit disturbing to see that it's cosponsored by
Sens. Patrick Leahy & Russ Feingold, who led the Senate opposition to the
Indecent Act. I find it hard to imagine that the bill will encounter any
significant legislative obstacles.

-Futplex 

From jya at pipeline.com  Mon Oct 30 10:16:54 1995
From: jya at pipeline.com (John Young)
Date: Tue, 31 Oct 1995 02:16:54 +0800
Subject: DOD_com
Message-ID: <199510301650.LAA13111@pipe1.nyc.pipeline.com>

   10-30-95. Wash Rag:

   "Pentagon Plans More Espionage. Business Fronts Abroad
   Would Expand Efforts Of a Unified Service."

      The Defense Department has merged its separate covert
      intelligence operations and plans to expand its
      espionage abroad, starting with establishment of phony
      businesses overseas as cover, and has formed the Defense
      HUMINT (Human Intelligence) Service, or DHS. Under the
      fiscal 1996 intelligence authorization bill, the DHS has
      been given a trial period of three years to carry on
      commercial activities "to provide cover security to
      intelligence collection activities undertaken abroad."
      The authority "to provide bona fide commercial cover,"
      was so that DHS's covert operatives could "withstand
      detailed investigation by hostile foreign intelligence
      services as well as domestic scrutiny."

      ... scandal of the Army's Yellow Fruit op ...

      CIA case officers are working with DHS on the cover
      companies abroad; cooperation is needed because in
      recent years military spies overseas inadvertently had
      set up relations with foreigners known to be double
      agents.

      Sen. Bob Kerrey called on CIA Director John M. Deutch to
      "develop his human collectors, planning 10 or more years
      in advance for their peak usefulness," a reference to
      placing them abroad under deep cover for use in future
      crises.

   DOD_com  (8 kb)

From mark at grondar.za  Mon Oct 30 10:42:16 1995
From: mark at grondar.za (Mark Murray)
Date: Tue, 31 Oct 1995 02:42:16 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510301816.UAA14080@grumble.grondar.za>

>    > > On this same track, I suggest that "/dev/random" devices for unix are
>    > > an excellent idea. Ted Tso did one for Linux that steals all the bits
>    > > of semi-random timing information it can.
>    >
>    > Anyone know where I can find more information on this wonderful device?
> 
> I've just sent patches (versus the Linux 1.3.28 kernel) off to Linus.
> There's a fairly long exposition at the beginning of
> drivers/char/random.c which explain its theory of operation.

A colleague drew my attention to this, and I was so pleased with it that
I ported it to FreeBSD.

I kept the interface as close to the original as I could, but made some
changes for efficiency and ease:

1) I turned the huge comment at the top explaining the theory of operation
into a man page (random(4)).

2) We felt that hooking all interrupts might be dangerous. IDE drives can
interrupt at a heck of a rate, and so can some serial ports, and we felt
that in these cases _not_ using the interrupt was a good idea. So I
added an ioctl to allow the superuser to select his own set, appropriate
to the hardware in use. It is nearly impossible to do this automatically.

Gimme a yell if you want copies :-)

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From s1113645 at tesla.cc.uottawa.ca  Mon Oct 30 10:42:53 1995
From: s1113645 at tesla.cc.uottawa.ca (s1113645 at tesla.cc.uottawa.ca)
Date: Tue, 31 Oct 1995 02:42:53 +0800
Subject: Cuban Security Conference
In-Reply-To: <199510301723.JAA22047@ix9.ix.netcom.com>
Message-ID: 

On Mon, 30 Oct 1995, Bill Stewart wrote:

> I wonder if they'd be receptive to talks on private communications,
> digicash, tax avoidance through digital technology, anarchy and
> collapse of government power, etc. :-)   (Maybe they would;

For that matter is civilian use of strong (or any other kind) crypto actually
legal in Cuba? Anyone know the policies? (duh, lemme guess...)

From ses at tipper.oit.unc.edu  Mon Oct 30 10:46:42 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Tue, 31 Oct 1995 02:46:42 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
Message-ID: 

To summarise: the consensus is that using keyed-MD5 for authentication is 
ok under ITAR, but using it for confidentiality is out.

The reason I wanted to check is that I'm solidifying some of security 
paramaters for HTTP-NG so we can add them to the test implementation 
before the Dallas IETF. In addition to the slight problem of having half 
the development team on the other side of the Atlantic, I want to make at 
least a subset of the security schemes mandatory, and that means making 
the core stuff exportable.

At the moment, I'm thinking of making the mandatory schemes be Keyed MD5
for authentication, and weakened RC4 with an IV for confidentiality, with
the added stipulation being that the user must be informed when key
weakening is being used. I may swap RC4 for DES; they're both public 
domain, but RC4 is simpler. They're both shared key, but I don't make PK 
stuff mandatory. 

The other pre-defined schemes I'm planning on getting at least speced are 
3-DES and IDEA for confidetiality, SHA for hashing, and RSA & DH for 
key exchange, signatures, and authentication. Certificate format is 
currently X.509- PGP format will go in ASAP.

Simon

---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From mark at unicorn.com  Mon Oct 30 11:14:14 1995
From: mark at unicorn.com (Rev. Mark Grant)
Date: Tue, 31 Oct 1995 03:14:14 +0800
Subject: Don't Kill the Messenger--A New Slant on Remailers
Message-ID: 

On Sun, 29 Oct 1995, Bill Stewart wrote:

> More of a problem with this system is that it's only useful for terminal
> remailers; to use it in the middle of a chain, the next remailer would
> need to be configured to auto-accept such messages, or else your remailer
> would need to have a list of known remailers and use direct delivery
> for all mail sent to them.

That's not a problem with Mixmaster, as it already knows whether the 
message is the last hop of a chain or not. I was hoping to get my hack 
finished this weekend, but got caught up in CTCP instead (which I'll 
release once I find out why it kills my xterm on exit 8-()..

	Mark

From black at sunflash.eng.usf.edu  Mon Oct 30 11:40:01 1995
From: black at sunflash.eng.usf.edu (James Black)
Date: Tue, 31 Oct 1995 03:40:01 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: 
Message-ID: 

Hello,

On Mon, 30 Oct 1995, Simon Spero wrote:

> The reason I wanted to check is that I'm solidifying some of security 
> paramaters for HTTP-NG so we can add them to the test implementation 
> before the Dallas IETF. In addition to the slight problem of having half 
> the development team on the other side of the Atlantic, I want to make at 
> least a subset of the security schemes mandatory, and that means making 
> the core stuff exportable.

  Since you deal with security issues maybe you can help me to learn 
about some issues with encryption.  I am talking with one of the 
administration people about putting PGP on the system for everyone to 
use, but there are issues for them (the admin) as they might be liable, 
even if they can't read the e-mail.  What other legal considerations 
should be evaluated?
  Is there any large organizations (like any other universities) that 
allow their students to use PGP, and have the system in place to make it 
easier for the students?  If it is offered here I might be the one to add 
to the mail program (pine) that is generally used to transparently use 
PGP, which is what I mean by having a system set up for the encryption. 
  Thanx for any help.  Take care and have fun.

James Black
black at suntan.eng.usf.edu

From spector at zeitgeist.com  Mon Oct 30 12:10:19 1995
From: spector at zeitgeist.com (David HM Spector)
Date: Tue, 31 Oct 1995 04:10:19 +0800
Subject: Important Digital Cash Question...
In-Reply-To: 
Message-ID: <199510301923.OAA09371@zeitgeist.zeitgeist.com>

um... perhaps, Ursula the Underwriter...?

regards,
  David
-----------------------------------------------------------------------------
David HM Spector				Software Developer & Nice Guy
http://zeitgeist.com				spector at zeitgeist.com
voice: +1 212.721.6974				fax: +1 212.721.9084
                               --------
SJM, 32, seeks SJF for meaningful rel... What? This ISN'T the VOICE personals?!

From lethin at ai.mit.edu  Mon Oct 30 13:06:25 1995
From: lethin at ai.mit.edu (Rich Lethin)
Date: Tue, 31 Oct 1995 05:06:25 +0800
Subject: [joanne@theory.lcs.mit.edu: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!!]
Message-ID: <199510301948.OAA01069@grape-nuts.ai.mit.edu>

From: joanne at theory.lcs.mit.edu (Joanne Talbot)
Date: Mon, 30 Oct 95 12:23:33 EST
To: theory-seminars at theory.lcs.mit.edu
Reply-To: theory-seminars-request at theory.lcs.mit.edu
Subject: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!!

                       MIT TOC SEMINAR

                 Thursday, November 2, 1995

       Refreshments at 4:00pm, Talk at 4:15pm in NE43-518

       ``Quantum Cryptoanalysis of Hidden Linear Forms''

                        by Dan Boneh
                    Princeton University

                         ABSTRACT

Recently there has been a great deal of interest in the power of
Quantum Computers. The driving force is the recent beautiful result of
Shor that shows that discrete log and factoring are solvable in random
quantum polynomial time. We use a method similar to Shor's to obtain a
general theorem about quantum polynomial time. We show that any
cryptosystem based on what we refer to as a `hidden linear form' can
be broken in quantum polynomial time. Our results imply that the
discrete log problem is doable in quantum polynomial time over any
group including Galois fields and elliptic curves.

Joint work with Richard Lipton.

Host: Shafi Goldwasser

From mark at grondar.za  Mon Oct 30 13:12:39 1995
From: mark at grondar.za (Mark Murray)
Date: Tue, 31 Oct 1995 05:12:39 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510301925.VAA27116@grumble.grondar.za>

>    Date: Mon, 30 Oct 1995 20:16:24 +0200
>    From: Mark Murray 
> 
>    A colleague drew my attention to this, and I was so pleased with it that
>    I ported it to FreeBSD.
> 
> Which version did you grab?  More recent versions of the driver use a
> more efficient mixing algorithm suggested by Colin Plum.  There's also
> the beginnings of support for user-mode deamons to add randomness into
> the random pool by writing to /dev/random.  I also added support for
> reading the instruction timing register for x86 platforms that support
> it. 

Version 0.92 21st Sept 1995.

Something I didn't mention earlier; we felt that letting the unwashed
masses read /dev/*random was not a good idea, as they could deplete
the pool of entropy all to easily for attack purposes. For the same
(or similar) reason, giving the said unwashed masses _write_ privelige
might allow them to set /dev/*random to a known state. You've probably
already thought of this, but I just had to say it :-).

>    2) We felt that hooking all interrupts might be dangerous. IDE drives can
>    interrupt at a heck of a rate, and so can some serial ports, and we felt
>    that in these cases _not_ using the interrupt was a good idea. So I
>    added an ioctl to allow the superuser to select his own set, appropriate
>    to the hardware in use. It is nearly impossible to do this automatically.
> 
> Indeed; I can't emphasize this enough.  The clock interrupt, for
> example, is a very bad irq to try to use.  In the Linux driver, only
> device drivers who register their interrupt driver with the
> SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for
> the random number generator.

(Hmm.. Thinks of ways of doing something similar. I'm not functioning too
well right now.)

> People have suggested using making it possible to select at run-time
> which interrupts to sample, instead of at compiling it into the device
> drivers.  I've generally not been convinced this is a good idea, because
> most system administrator won't likely know which irq's are good and
> which are bad for random number generation.  For example, although it
> may not be obvious, the network interrupt may not be a good choice,
> since an adversary who is monitoring the ethernet cable can make a
> pretty good guess about the timing of your network interrupts, and hence
> what the likely inputs are to the random number pool might be.

Are you sure about this? The stochastisity if this would be pretty
hefty. Not only would our attacker have to get the _time_ that the
interrupt occurred (if it interrupted our machine), he would then have
to process in brute-force mode all possible times in his error range.
What is more, more interrupts are coming in...

>    Gimme a yell if you want copies :-)
> 
> Sure, why not.   I'd be interested to see what you did.

Hokay! Please also send me _your_ latest. (BTW - did Linus put it in
his latest kernel?)

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From tytso at MIT.EDU  Mon Oct 30 13:26:43 1995
From: tytso at MIT.EDU (Theodore Ts'o)
Date: Tue, 31 Oct 1995 05:26:43 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510301816.UAA14080@grumble.grondar.za>
Message-ID: <9510301856.AA22851@dcl.MIT.EDU>

   Date: Mon, 30 Oct 1995 20:16:24 +0200
   From: Mark Murray 

   A colleague drew my attention to this, and I was so pleased with it that
   I ported it to FreeBSD.

Which version did you grab?  More recent versions of the driver use a
more efficient mixing algorithm suggested by Colin Plum.  There's also
the beginnings of support for user-mode deamons to add randomness into
the random pool by writing to /dev/random.  I also added support for
reading the instruction timing register for x86 platforms that support
it. 

   2) We felt that hooking all interrupts might be dangerous. IDE drives can
   interrupt at a heck of a rate, and so can some serial ports, and we felt
   that in these cases _not_ using the interrupt was a good idea. So I
   added an ioctl to allow the superuser to select his own set, appropriate
   to the hardware in use. It is nearly impossible to do this automatically.

Indeed; I can't emphasize this enough.  The clock interrupt, for
example, is a very bad irq to try to use.  In the Linux driver, only
device drivers who register their interrupt driver with the
SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for
the random number generator.

People have suggested using making it possible to select at run-time
which interrupts to sample, instead of at compiling it into the device
drivers.  I've generally not been convinced this is a good idea, because
most system administrator won't likely know which irq's are good and
which are bad for random number generation.  For example, although it
may not be obvious, the network interrupt may not be a good choice,
since an adversary who is monitoring the ethernet cable can make a
pretty good guess about the timing of your network interrupts, and hence
what the likely inputs are to the random number pool might be.

   Gimme a yell if you want copies :-)

Sure, why not.   I'd be interested to see what you did.

						- Ted

From futplex at pseudonym.com  Mon Oct 30 13:27:28 1995
From: futplex at pseudonym.com (Futplex)
Date: Tue, 31 Oct 1995 05:27:28 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: 
Message-ID: <199510302038.PAA21082@opine.cs.umass.edu>

Simon writes:
> I may swap RC4 for DES; they're both public domain, but RC4 is simpler. 

Er, at last report RSADSI was still claiming RC4 as a trade secret, in spite
of the posting of the (convincing) alleged RC4.

-Futplex 

From rsalz at osf.org  Mon Oct 30 13:33:45 1995
From: rsalz at osf.org (Rich Salz)
Date: Tue, 31 Oct 1995 05:33:45 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
Message-ID: <9510301954.AA07200@sulphur.osf.org>

>At the moment, I'm thinking of making the mandatory schemes be Keyed MD5
>for authentication, and weakened RC4 with an IV for confidentiality, with
>the added stipulation being that the user must be informed when key
>weakening is being used. I may swap RC4 for DES; they're both public 
>domain, but RC4 is simpler. They're both shared key, but I don't make PK 
>stuff mandatory. 

The licensed version of RC4, or the software that was posted anonymously?

Do you really feel comfortable basing an IETF standard on that?  When
you use the term RC4 do you mean the real version or the posted one,
what will you do if they ever conflict?  Can you even use the name RC4
for the posted version?  It seems to me that RC4 means the RSA licensed
code, which presumably you wanted to avoid when you wrote no mandatory PK.

Where would you swap RC4 for DES?

I assume your added stipulation is a "should" not a "must" item.

How are you going to handle key management and naming?
	/r$

From ses at tipper.oit.unc.edu  Mon Oct 30 14:48:34 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Tue, 31 Oct 1995 06:48:34 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510301954.AA07200@sulphur.osf.org>
Message-ID: 

On Mon, 30 Oct 1995, Rich Salz wrote:

> The licensed version of RC4, or the software that was posted anonymously?

Cop-out: That algorithm described in Applied Cryptography 2nd Edition 
under the label RC4.

> Where would you swap RC4 for DES?

The swap would take place in the list of schemes that must be supported 
by conforming applications. 

> I assume your added stipulation is a "should" not a "must" item.

Correct [strong should, but still should]

> How are you going to handle key management and naming?

The protocol's part of key management for OOB shared keys is taken care 
of by naming; session key exchange with PK is not yet fully defined, but 
will  look a lot like either SKIP or Photuris. 

Naming:
   Names are strings, of the format :, where domain is the
name-space from which the names are taken. The following domains are
pre-defined: 

DN:	X.500 Distinguished name. The name portion contains the RFC1485 
	ascii encoding of the DN.

URN:	Uniform Resource Name. The name consists of a URN (whatever that 
	turns out to be).

PGP:	PGP format name. A PGP user name.

Simon
----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From tytso at MIT.EDU  Mon Oct 30 15:10:10 1995
From: tytso at MIT.EDU (Theodore Ts'o)
Date: Tue, 31 Oct 1995 07:10:10 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510301925.VAA27116@grumble.grondar.za>
Message-ID: <9510302119.AA24959@dcl.MIT.EDU>

   Date: Mon, 30 Oct 1995 21:25:50 +0200
   From: Mark Murray 

   Version 0.92 21st Sept 1995.

Yup, there's a more recent version in the Linux tree at this point.

   Something I didn't mention earlier; we felt that letting the unwashed
   masses read /dev/*random was not a good idea, as they could deplete
   the pool of entropy all to easily for attack purposes. 

That should be a system administration issue.  If someone wants to make
/dev/random readable only by root at their site, that's their business.
I don't see any point in trying to enforce that in the kernel code.

I don't agree that restricting read access is useful.  First of all, if
the pool of entropy is depleted, someone who tries to obtain entropy by
reading /dev/random will know that they didn't get enough entropy.  So
assuming a program that actually checks return values from system calls,
this is at worse a denial of service attack, and there are much easier
ways of performing those srots of attacks: "while (1) fork()", for
example.

Secondly, making /dev/random only readable by "privileged programs"
means that people won't be able to compile their own version of PGP that
can take advantage of the random number generator.  Instead, they would
have to use a setuid version of PGP, and I'm quite sure PGP wasn't
written such that it would be safe to turn on its setuid bit.  

Finally, even if you did have trustworthy applications which you could
setuid and only allow those programs to have access to /dev/random,
someone who repeatedly ran those applications could still end up
depleteing the pool of entropy.

So in the general case I would advise that /dev/random be left world
readable, since you *do* want general user programs to have access to
high quality random numbers.  

   For the same (or similar) reason, giving the said unwashed masses
   _write_ privelige might allow them to set /dev/*random to a known
   state. You've probably already thought of this, but I just had to say
   it :-).

Again, /dev/random can be set to whatever permissions the system
administrator wants.  Secondly, writing to /dev/random merely adds
randomness to the pool, via the mixing algorithm.  It won't actually
permit people to *set* the state of the pool, and assuming that the
state of the pool is not known before the write operation, writing to it
won't allow the user to know what the state is after the write
operation.

The ioctl() which sets the entropy estimate, however, *does* need to be
runnable only by the superuser, however, since that does represent an
attack path.

And, for race condition reasons, something which I need to implement
soon is an ioctl(), usuable only by root, that simultaneously updates
the entropy estimate *and* submits data to be mixed into the pool.  (Why
this is necessary should be obvious after a few minutes thought.)

   > For example, although it
   > may not be obvious, the network interrupt may not be a good choice,
   > since an adversary who is monitoring the ethernet cable can make a
   > pretty good guess about the timing of your network interrupts, and hence
   > what the likely inputs are to the random number pool might be.

   Are you sure about this? The stochastisity if this would be pretty
   hefty. Not only would our attacker have to get the _time_ that the
   interrupt occurred (if it interrupted our machine), he would then have
   to process in brute-force mode all possible times in his error range.
   What is more, more interrupts are coming in...

I didn't say that it would be trivial for an attacker to do this, but
it's certainly *doable*.  Some of the network traffic analyzers that
have been made available (I think Sandia National Labs has one that does
this), records down to millisecond accuracy when a packet was sniffed on
the network.  

For this reason, people shouldn't really trust initializing PGP's random
number generator over a network connection, since it is possible for an
adversary to obtain very high quality timings of when your telnet or
rlogin packets appeared on the network, and hence be able to guess
(within some error range) what the interkeyboard timings which PGP used
to initialize its random number generator.

The adversary might have to try a large number of possibilities, but if
the number of possibilities is less than a brute-force search, you
definitely have a weakness --- a fact which Netscape learned to its
embarassment a few weeks ago.

   Hokay! Please also send me _your_ latest. (BTW - did Linus put it in
   his latest kernel?)

Yup.  1.1.34 and higher has most of my changes.  (I'm still making
changes which are still in development, though.  Mostly incremental
improvements of one sort or another.)

							- Ted

From mark at grondar.za  Mon Oct 30 15:36:57 1995
From: mark at grondar.za (Mark Murray)
Date: Tue, 31 Oct 1995 07:36:57 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510302148.XAA00832@grumble.grondar.za>

>    Something I didn't mention earlier; we felt that letting the unwashed
>    masses read /dev/*random was not a good idea, as they could deplete
>    the pool of entropy all to easily for attack purposes. 
> 
> That should be a system administration issue.  If someone wants to make
> /dev/random readable only by root at their site, that's their business.
> I don't see any point in trying to enforce that in the kernel code.

Is not in the kernel, this is just the permissions on /dev/*random.

> I don't agree that restricting read access is useful.  First of all, if
> the pool of entropy is depleted, someone who tries to obtain entropy by
> reading /dev/random will know that they didn't get enough entropy.  So
> assuming a program that actually checks return values from system calls,
> this is at worse a denial of service attack, and there are much easier
> ways of performing those srots of attacks: "while (1) fork()", for
> example.

Hmm. Lemme think about this...

> Secondly, making /dev/random only readable by "privileged programs"
> means that people won't be able to compile their own version of PGP that
> can take advantage of the random number generator.  Instead, they would
> have to use a setuid version of PGP, and I'm quite sure PGP wasn't
> written such that it would be safe to turn on its setuid bit.  

How about SetGID? We were going for 660 root.kmem.

> Finally, even if you did have trustworthy applications which you could
> setuid and only allow those programs to have access to /dev/random,
> someone who repeatedly ran those applications could still end up
> depleteing the pool of entropy.
> 
> So in the general case I would advise that /dev/random be left world
> readable, since you *do* want general user programs to have access to
> high quality random numbers.  

Ponder... I'll put this forward.

> Again, /dev/random can be set to whatever permissions the system
> administrator wants.  Secondly, writing to /dev/random merely adds
> randomness to the pool, via the mixing algorithm.  It won't actually
> permit people to *set* the state of the pool, and assuming that the
> state of the pool is not known before the write operation, writing to it
> won't allow the user to know what the state is after the write
> operation.

What happens if some attacker does:

for (;;) {
	write_to_devrandom(NULL);
	check_to_see_if_state_is_crackable();
}

? "Gut feel" suggests to me that large ammounts of "predicted" input might
be worse than the normal sort of system noise you have been using.

> And, for race condition reasons, something which I need to implement
> soon is an ioctl(), usuable only by root, that simultaneously updates
> the entropy estimate *and* submits data to be mixed into the pool.  (Why
> this is necessary should be obvious after a few minutes thought.)

Clue me in - I'm not quite with you? :-)

>    Are you sure about this? The stochastisity if this would be pretty
>    hefty. Not only would our attacker have to get the _time_ that the
>    interrupt occurred (if it interrupted our machine), he would then have
>    to process in brute-force mode all possible times in his error range.
>    What is more, more interrupts are coming in...
> 
> I didn't say that it would be trivial for an attacker to do this, but
> it's certainly *doable*.  Some of the network traffic analyzers that
> have been made available (I think Sandia National Labs has one that does
> this), records down to millisecond accuracy when a packet was sniffed on
> the network.  

Is this millisecond accuracy quantifiable in terms of bits of entropy?
if so, the ethernet is surely safe?

> For this reason, people shouldn't really trust initializing PGP's random
> number generator over a network connection, since it is possible for an
> adversary to obtain very high quality timings of when your telnet or
> rlogin packets appeared on the network, and hence be able to guess
> (within some error range) what the interkeyboard timings which PGP used
> to initialize its random number generator.
> 
> The adversary might have to try a large number of possibilities, but if
> the number of possibilities is less than a brute-force search, you
> definitely have a weakness --- a fact which Netscape learned to its
> embarassment a few weeks ago.

Again, if you can quantify the number of possibilities into bits of entropy,
your code is good. Depending on current technology, this may have to change.

M

--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From tytso at MIT.EDU  Mon Oct 30 15:47:22 1995
From: tytso at MIT.EDU (Theodore Ts'o)
Date: Tue, 31 Oct 1995 07:47:22 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510302148.XAA00832@grumble.grondar.za>
Message-ID: <9510302225.AA25562@dcl.MIT.EDU>

   Date: Mon, 30 Oct 1995 23:48:24 +0200
   From: Mark Murray 

   > Secondly, making /dev/random only readable by "privileged programs"
   > means that people won't be able to compile their own version of PGP that
   > can take advantage of the random number generator.  Instead, they would
   > have to use a setuid version of PGP, and I'm quite sure PGP wasn't
   > written such that it would be safe to turn on its setuid bit.  

   How about SetGID? We were going for 660 root.kmem.

Bad idea; anyone who can run PGP could then get instant access to kmem

	cd /tmp
	ln -s /dev/kmem foo
	pgp -e tytso foo
	rm foo
	pgp foo.pgp

   > Again, /dev/random can be set to whatever permissions the system
   > administrator wants.  Secondly, writing to /dev/random merely adds
   > randomness to the pool, via the mixing algorithm.  It won't actually
   > permit people to *set* the state of the pool, and assuming that the
   > state of the pool is not known before the write operation, writing to it
   > won't allow the user to know what the state is after the write
   > operation.

   What happens if some attacker does:

   for (;;) {
	   write_to_devrandom(NULL);
	   check_to_see_if_state_is_crackable();
   }

   ? "Gut feel" suggests to me that large ammounts of "predicted" input might
   be worse than the normal sort of system noise you have been using.

But keep in mind that what we're doing is XOR'ing the input data into
the pool.  (Actually, it's a bit more complicated than that.  The input
is XOR'ed in with a CRC-like function, generated by taking an
irreducible polynomial in GF(2**128).  But for the purposes of this
argument, you can think of it as XOR.)  So since you don't know what the
input state of the pool is, you won't know what the output state of the
pool.

Also, you never get to see the actual state of the pool, even when you
read out numbers from /dev/random.  What you're getting is a *hash* of
the pool.  So if you can actually implement
check_to_see_if_state_is_crackable(), then you've found a weakness in
MD5 (or SHA, to which I'll probably be switching in the near future).

   > And, for race condition reasons, something which I need to implement
   > soon is an ioctl(), usuable only by root, that simultaneously updates
   > the entropy estimate *and* submits data to be mixed into the pool.  (Why
   > this is necessary should be obvious after a few minutes thought.)

   Clue me in - I'm not quite with you? :-)

Consider this scenario:

1)  Process one writes randomness to /dev/random.

2)  Process two immediately consumes a large amount of randomness using
/dev/urandom, so that the effective randomness is now zero.

3)  Process two uses the ioctl() to bump the entropy count by the amount
of randomness added in step 1.  Unfortunately, that entropy was already
consumed in step 2.

   > I didn't say that it would be trivial for an attacker to do this, but
   > it's certainly *doable*.  Some of the network traffic analyzers that
   > have been made available (I think Sandia National Labs has one that does
   > this), records down to millisecond accuracy when a packet was sniffed on
   > the network.  

   Is this millisecond accuracy quantifiable in terms of bits of entropy?
   if so, the ethernet is surely safe?

Well, no.  If you're only using as your timing the 100Hz clock, the
adversary will have a better timebase than you do.  So you may be adding
zero or even no bits of entropy which can't be deduced by the adversary.

This is even worse in the PGP keyboard timing case, since the adversary
almost certainly can find a better time resolution to measure your
incoming packets when compared to the timing resolution that most
programs have.  Far too many Unix systems only make a 100Hz clock
available to the user mode, even if you have a better quality high
resolution timing device in the kernel (for example, the Pentium cycle
counting register).

   Again, if you can quantify the number of possibilities into bits of entropy,
   your code is good. Depending on current technology, this may have to change.

The problem is that in order to do this requires making assumptions
about what the capabilities of your adversary are.  Not only does this
change over time, but certain adversaries (like the NSA) make it their
business to conceal their capabilities, for precisely this reason.

So I like to be conservative and use limits which are imposed by the
laws of physics, as opposed to the current level of technology.  Hence,
if the packet arrival time can be observed by an outsider, you are at
real risk in using the network interrupts as a source of entropy.
Perhaps it requires buidling a very complicated model of how your Unix
scheduler works, and how much time it takes to process network packets,
etc.  ---- but I have to assume that an adversary can very precisely
model that, if they were to work hard enough at it.

People may disagree as to whether or not this is possible, but it's not
prevented by the laws of physics; merely by how much effort someone
might need to put in to be able to model a particular operating system's
networking code.  In any case, that's why I don't like depending on
network interrupts.  Your paranoia level may vary.

						- Ted

From shields at tembel.org  Mon Oct 30 15:47:44 1995
From: shields at tembel.org (Michael Shields)
Date: Tue, 31 Oct 1995 07:47:44 +0800
Subject: Digicash will not fly (not)
In-Reply-To: 
Message-ID: <473jfp$pll@yage.tembel.org>

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

In article ,
Simon Spero  wrote:
> One point worth noting is that the 5% cut used to be a typical fee for 
> credit-card transactions. However, that cut only happened once per 
> purchace, whereas digicash may incur this fee many more times. 

I think there are two major differences between credit cards and digicash
that affect the pricing structure.

1. Applicability

We think of eventually using digicash for everything.  You wouldn't just
use it to pay Sears for a sweater, but Sears would use it to pay for the
wool and for their taxes.  A 5% hit may be ok for the final transaction,
but it's impossible if you incur it every time money is exchanged.

Credit cards are mostly consumer items and don't have this problem as
much, and the states have invented resale licenses specifically to exempt
you from paying sales tax at every step.  I realize that digicash is being
marketed as a consumer item, but I'd like to see it eventually become a
standard banking instrument.  I certianly trust it more than I trust EFT.

2. Float

Cash schemes are unique in that while your money is in the ecash mint,
the bank has the use of it.  Don't underestimate the importance of this
in a high-volume business; if digicash were popular, the banks would
cut their margins to the point where this would probably be the major
source of revenue.  But it would be substantial.

I think digicash out to be priced comparably to traveller's checks.
That is what they are closest to.

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

iQCVAwUBMJVRJOyjYMb1RsVfAQGMeQP/eg77ud1E1lyoWhERLkHXOawHaaUXcz/j
mZoCD4ujmkiBmOmvqCyITG9UFOKSjzJ4aA8AC81AVPhCxVLIahMLZBFb2IvANz4r
jLJraWyBNWpLk4TN/djwPcMdtMcQsAMTWB5IYeQDvp3IWS/rnIr01Zs0RiKYlE3q
7X5zuwDMujc=
=BBfH
-----END PGP SIGNATURE-----
-- 
Shields.

From shields at tembel.org  Mon Oct 30 16:02:31 1995
From: shields at tembel.org (Michael Shields)
Date: Tue, 31 Oct 1995 08:02:31 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510301925.VAA27116@grumble.grondar.za>
Message-ID: <473k3p$pt2@yage.tembel.org>

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

In article <199510301925.VAA27116 at grumble.grondar.za>,
Mark Murray  wrote:
> Something I didn't mention earlier; we felt that letting the unwashed
> masses read /dev/*random was not a good idea, as they could deplete
> the pool of entropy all to easily for attack purposes.

That's really just a DOS attack, isn't it?  An application that needs
true randomness should be using /dev/random, which you can slow but not
disturb, and an application that is using /dev/urandom should be ok with
less than full entropy.

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

iQCVAwUBMJVTqeyjYMb1RsVfAQGqYwP/W6xUdsxwCMrWlvmuPrfV4yfaYpZWt3JW
/ld8HsqyQt5XRkbNwq/hcXDle13exEaqzXe2l6qHtR3qySEaU/4WF/BgSTwqpQa+
iA6p8KL51XPluNF9oagMrmOR2J4yxMPldrx5m/+WcZRJj4mdfzxQoMQ9J4agTVsC
l2spGY8iNkA=
=9cfz
-----END PGP SIGNATURE-----
-- 
Shields.

From Doug.Hughes at Eng.Auburn.EDU  Mon Oct 30 17:14:59 1995
From: Doug.Hughes at Eng.Auburn.EDU (Doug Hughes)
Date: Tue, 31 Oct 1995 09:14:59 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: 
Message-ID: 

>  Since you deal with security issues maybe you can help me to learn 
>about some issues with encryption.  I am talking with one of the 
>administration people about putting PGP on the system for everyone to 
>use, but there are issues for them (the admin) as they might be liable, 
>even if they can't read the e-mail.  What other legal considerations 
>should be evaluated?
>  Is there any large organizations (like any other universities) that 
>allow their students to use PGP, and have the system in place to make it 
>easier for the students?  If it is offered here I might be the one to add 
>to the mail program (pine) that is generally used to transparently use 
>PGP, which is what I mean by having a system set up for the encryption. 
>  Thanx for any help.  Take care and have fun.
>
>James Black
>black at suntan.eng.usf.edu
>
>
We have approx 1000 machines and 5000 user accounts and have pgp installed.
I can't think of any reason not to have it installed, and lots of good
reasons for having it installed.

--
____________________________________________________________________________
Doug Hughes					Engineering Network Services
System/Net Admin  				Auburn University
			doug at eng.auburn.edu
	Apple T-shirt on Win95 - "Been there, done that"

From llurch at networking.stanford.edu  Mon Oct 30 18:17:33 1995
From: llurch at networking.stanford.edu (Rich Graves)
Date: Tue, 31 Oct 1995 10:17:33 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: 
Message-ID: 

On Mon, 30 Oct 1995, Doug Hughes wrote:

> >  Since you deal with security issues maybe you can help me to learn 
> >about some issues with encryption.  I am talking with one of the 
> >administration people about putting PGP on the system for everyone to 
> >use, but there are issues for them (the admin) as they might be liable, 
> >even if they can't read the e-mail.  What other legal considerations 
> >should be evaluated?
> >  Is there any large organizations (like any other universities) that 
> >allow their students to use PGP, and have the system in place to make it 
> >easier for the students?  If it is offered here I might be the one to add 
> >to the mail program (pine) that is generally used to transparently use 
> >PGP, which is what I mean by having a system set up for the encryption. 
> >
> We have approx 1000 machines and 5000 user accounts and have pgp installed.
> I can't think of any reason not to have it installed, and lots of good
> reasons for having it installed.

"Me too," except the numbers are higher.

I would think that you would worry more about your users getting a false
sense of security from storing secret keys on a large multiuser system
than about being held liable for naughty PGP-encrypted traffic. I don't 
see how you could be held liable anyway. How is PGP that much different 
from allowing your users to set a password on their account? It makes it 
harder for root to invade their privacy, but in general, we have very 
stringent requirements that must be satisfied before we'll read user 
directories or mail.

-rich

From ses at tipper.oit.unc.edu  Mon Oct 30 18:21:14 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Tue, 31 Oct 1995 10:21:14 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510302351.AA28243@zorch.w3.org>
Message-ID: 

On Mon, 30 Oct 1995 hallam at w3.org wrote:

> 	Do not spec Keyed MD5, it is a complete looser. It is actually weak
> against a number of attacks. There are much better constructs for creating

What I've heard is that there are some worries about using short 
constants with MD5; maybe you could fill us in on the naughty stuff 
(someone said there were a load of papers in Crypto '95 on the subject?)

> 
> 	There is some work by Phil Rogaway on making keyed digest functions
> which I strongly recommend people look at. I can post a paper on the subject if 
> people are interested.

Hey, you got a web-site? :-)

Simon

----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From baldwin at RSA.COM  Mon Oct 30 18:24:00 1995
From: baldwin at RSA.COM (baldwin (Robert W. Baldwin))
Date: Tue, 31 Oct 1995 10:24:00 +0800
Subject: Keyed-MD5, and HTTP-NG
Message-ID: <9509308151.AA815103202@snail.rsa.com>

Simon,
        There are a few different ways to add key material to MD5 to
make it suitable as a shared-secret authenticator function.  Some of these
are less resistant to attacks than others.  For example, the keyed MD5
mechanism that is part of the current IPsec specifications can be
attacked using 2**60 chosen messages.  Fortunately, the IPsec specs
also require that the shared MD5 key be changed every 2**32 messages,
so this attack is unlikely to succeed.  Specifically, IPsec uses
MD5 as follows:  X = MD5(key | keypad | Message), where "|" means
concatenation and the "keypad" pads out the key to 512 bits.
Basically, this function is the same as standard MD5 with a
different initialization vector for the compression operation
on the first block of the message.
        RSA Labs recommends that a people use an authenticator like
X = MD5(key1, MD5(key2, Message)).  This resists the chosen plaintext
attacks that were published at the crypto conference in Spring 1995.
        There are also some very fast MAC algorithms being proposed
these days.  As Phill Hallam mentioned, you may want to look at the
work of Phil Rogaway.  At a minimum, make sure that your standard
allows people to migrate from a current solution based on MD5 to a
future solution based on new functions.  However, I would be relunctant
to require new functions until they have had a chance to be tested
by the cryptographic research community.
                --Bob Baldwin

From black at eng.usf.edu  Mon Oct 30 18:30:26 1995
From: black at eng.usf.edu (James Black)
Date: Tue, 31 Oct 1995 10:30:26 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: 
Message-ID: 

Hello,

On Mon, 30 Oct 1995, Rich Graves wrote:

> On Mon, 30 Oct 1995, Doug Hughes wrote:
> 
> I would think that you would worry more about your users getting a false
> sense of security from storing secret keys on a large multiuser system
> than about being held liable for naughty PGP-encrypted traffic. I don't 
> see how you could be held liable anyway. How is PGP that much different 
> from allowing your users to set a password on their account? It makes it 
> harder for root to invade their privacy, but in general, we have very 
> stringent requirements that must be satisfied before we'll read user 
> directories or mail.

  As a student I am concerned with the false security, and that was 
mentioned while we were talking (today).  As to liability, it is 
important that no one can come back and hold the school liable.  Once the 
messages can be encrypted then it is harder to read the messages, but not 
impossible, unless the students keep the key on a disk, and just ftp it 
into the account everytime.  The fact is that that won't be the rule, so 
the admin can still read messages, but there will need to be clear-cut 
reasons for them to do that (IMOHO).  I am curious what requirements must 
be met.  I guess there are more schools that allow this than I expected 
.  Well thanx for replying.  Take care and have fun.

James Black
black at suntan.eng.usf.edu

From weld at l0pht.com  Mon Oct 30 18:33:09 1995
From: weld at l0pht.com (Weld Pond)
Date: Tue, 31 Oct 1995 10:33:09 +0800
Subject: S. 1284 To Amend (C) Act
Message-ID: 

>>  S. 1284,  s1201:  "No person shall import, manufacture or distribute
>>  any device, product, or component incorporated into a device or
>>  product, or offer or perform any service, the primary purpose or
						  ^^^^^^^^^^^^^^^

>IANAL, but I thought these types of laws were already tested and deemed  
>unconstitutional in cases involving video-tape copying boxes, dual 
video  
>cassette dubbing decks, SCMS 'scrubbers', etc...

I think the large gray area here is the phrase primary purpose.  The 
primary purpose of a device is in the users mind only.  Videotape copying 
of noncopyright materials is done on a vast scale now due to home 
camcorders.  But even if only a few people had camcorders they should be 
able to purchase equipment that can be used legally.

Introducing the concept of "primary purpose" makes law abiding citizens 
suffer because some people are breaking the law.  If an item has any 
legal purpose it must be allowed.

This trend to take technology that *can* be used to commit crimes out of
the hands of citizen units is growing.  We see it with crypto export
controls and recently with the PA law and Federal law making it a crime to
posess devices and software to reprogram cell phones. 

When this doesn't make a dent in the number of these crimes I predict we 
will see licensing of technologies such as eeprom programmers, spectrum 
analyzers, frequency counters, and yes of course strong crypto.

      Weld Pond   -  weld at l0pht.com   -   http://www.l0pht.com/~weld
      L  0  p  h  t    H  e  a  v  y    I  n  d  u  s  t  r  i  e  s          
      Technical archives for the people  -  Bio/Electro/Crypto/Radio

From ericande at cnw.com  Mon Oct 30 18:45:15 1995
From: ericande at cnw.com (Eric Anderson)
Date: Tue, 31 Oct 1995 10:45:15 +0800
Subject: Article on PGP (Noise)
Message-ID: <01BAA6F2.B9A98120@king1-20.cnw.com>

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

        C'punks
        I saw a good article on PGP in this month's issue of American
Survival Guide. Not only did the article portray the use ofstrong crypto as a
good thing for privacy and liberty, it also tells the reader where to
obtain PGP. After that, the article goes into some of the issues surrounding
PGP such as ITAR, Phil Zimmerman's legal troubles (It even tells how to
contribute to his legal fund.) and how the government is really against it.
        After the background, the article gives clear, detailed, step by step
instructions on how to use it; from the inital unzipping of the program to
setup and key generation and management.
        All in all, I found this a very informative article for the new user
and even some of the more advanced users (Hey-you learn something new every
day, right?).
        It wasn't the type of article that wouldn't be covered in Time
or Newsweak that's for sure.

Eric

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

iQBVAwUBMJWDeyQV+sMsxjC5AQGT9QH9E8BHovGCmu7p9wB2nYQzmebqFPw3sfnR
2CuFTSvkdbg/4yArOsE87S+g28I2B/tscaVYdAO8HA5CdhVVAxbH0w==
=wjpi
-----END PGP SIGNATURE-----

From blancw at accessone.com  Mon Oct 30 19:02:49 1995
From: blancw at accessone.com (blancw at accessone.com)
Date: Tue, 31 Oct 1995 11:02:49 +0800
Subject: Pinkerton Risk Assessment & "Security 2000"
Message-ID: <9510300619.AA11035@pulm1.accessone.com>

I have been broswing through the MSN (Microsoft Network), and discovered a 
section in the "SOHO" (Small Home Owner's Guidebook) called "Partners Pages".  
In it there is a list of companies with icons which subscribers can click on to 
view these companies' business/financial-related services.

One of them is the Pinkerton Risk Assessment Service.  I opened & examined 
their several icons, and it suddenly occurred to me how useful this kind of 
on-line information could be to individuals in the new anarcho-capitalist, 
nationally-borderless world. 

Sort of in keeping with the theme which Sandy Sandfort and Duncan Frissell 
brought up with their "lectures" on "Risk" last year, as well as what I had 
said in an earlier post about people in our brave new world needing to become 
imaginative in providing for their own self-defense (seeing as how trusting the 
goverment doesn't work so well), it occurred to me that having information on 
threats to one's physical safety would be fitting for this need - like the RISK 
mailing list is for computers/software.  This kind of data would be different 
from what we can get on the regular news, which is combined with many other 
kinds of news and is very generalized, in that it deals more specifically with 
the subject.

They advertise their services as:

"... the risk assessment tool for the 21st century. If you or other members of 
your company travel internationally, the Global Risk Network  on MSN. is an 
invaluable service, keeping you informed of worldwide events, political 
turmoil, global sensitive spots, and more! Now you have direct online access to 
a wealth of exclusive Pinkerton information, all via your computer. You can 
even order hard copy reports or have customized research performed by Pinkerton 
Risk Assessment  experts, simply type in your request. Tailored for the 
individual traveler, as well as the corporate executive, our risk services give 
you several options to know the security situation anywhere."

Although their services are advertised for the corporate business traveler, it 
obviously is of use to any traveler, and particularly to the person who is in 
the location mentioned.  They have icons opening up to BBSes where they report 
on trouble spots and potential threats in a timely manner:

"The Global Risk Network provides even more detailed country data, including 
� The Daily Risk Assessment 
� Weekly Risk Assessment
� Special reports 
� Statistical analysis of significant incidents
   by country and region 
� Security tips 
� Eye on Travel "

You would think that if the NSA & other State Departments used their services, 
that they wouldn't need to poke around people's computers to better predict 
where to put added security for high honcho dignitaries or State office 
buildings.  But isn't that what the intelligence services are for?  Oh, well. 
Here, I thought, is a great service for the regular person which they can use 
to be prepared for the exigencies of life's little problems, like terrorists 
and other restive types with violence on their mind.

For any of you in the Washington, D.C. area, there will be a lecture from 
Pinkerton next week as detailed below.  If anyone from this list goes, it would 
be interesting to get a post on what they say - the section on cybersecurity 
might be of relevance to the list.

(I got this from the same location on their MSN site.):

IN COOPERATION WITH THE GEORGE WASHINGTON UNIVERSITY 
PRESENTS
SECURITY 2000 

Please join us at The George Washington University's Marvin Center on November 
9, 1995, for a seminar on topics of vital interest to security professionals. 
The seminar will highlight the opportunities and challenges of the security 
environment in China; computer crime and how it can affect your business; a 
global overview of political unrest, terrorism and crime,; and a demonstration 
of the new Pinkerton Global Risk Network on the Microsoft Network. Join us for 
the news, views and tools for ensuring your organization's security as we 
approach the 21st century.

Featuring: 
	0800-0900  China and Southeast Asia - Dan Grove, Pinkerton - Asia
	0910-1000  Cybercrime - Special Agent Jim Christy, 
		     Air Force Office of Special Investigations 
	1010-1110  Global Patterns and Trends - Hugh Barber, 
		     Pinkerton Risk Assessment Services
	1120-1220   Pinkerton Global Risk Network on the Microsoft Network
		      - Demonstrated by Frank Johns and Hugh Barber,
		        Pinkerton Risk Assessment Services
	1230-1400   Lunch - GWU Club (no charge)  

The GWU campus is just off the Foggy Bottom Metro stop, in Washington D.C., 
near the U.S. Department of State, where the annual OSAC conference will take 
place on November 7-8.  

There is no fee for the seminar, however, seating is limited. Please RSVP by 
calling Pinkerton Risk Assessment Services at (703) 525-6111, Fax (703) 
525-2454 or via e-mail at: pras at access.digex.net
--------------

  ..
Blanc

From stripes at va.pubnix.com  Mon Oct 30 19:36:57 1995
From: stripes at va.pubnix.com (Josh M. Osborne)
Date: Tue, 31 Oct 1995 11:36:57 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510302148.XAA00832@grumble.grondar.za>
Message-ID: 

In message <199510302148.XAA00832 at grumble.grondar.za>, Mark Murray writes:
[...]
>> I don't agree that restricting read access is useful.  First of all, if
>> the pool of entropy is depleted, someone who tries to obtain entropy by
>> reading /dev/random will know that they didn't get enough entropy.  So
>> assuming a program that actually checks return values from system calls,
>> this is at worse a denial of service attack, and there are much easier
>> ways of performing those srots of attacks: "while (1) fork()", for
>> example.
>
>Hmm. Lemme think about this...

When /dev/random doesn't have "enough" enthropy left does reading
from it return an error, or block?  I would strongly suggest
blocking, as the non-blocking behavur is not really all that useful.

Either can simulate the other, but I think it comes down to:

non-blocking worst-case:
 a program calls /dev/random, doesn't get randomness, ignores
 error code, poorly protects some valuable thing, as a result
 the valuable thing gets stolen.

blocking worst-case:
 a program calls /dev/random, waits a long time to get random numbers,
 user curses the slow machine/program, valuable thing gets sent late,
 but is not stolen.

non-blocking best-case failure:
 a program calls /dev/random, doesn't get randomness, informs smart
 user, who finds the bad guy sucking all bits from /dev/random,
 has them ejected from system.

blocking best-case failure:
 same as worst-case (i.e. the worst-case is lots better, the best-case
 is worse).  This can be transformed to the non-blocking best-case 
 failure by clever programming (threads, or fork, or sigalarm), the
 people who do this are far more likely to actually try to issue a
 good error message then the people who get non-blocking by default.

From tytso at MIT.EDU  Mon Oct 30 19:52:56 1995
From: tytso at MIT.EDU (Theodore Ts'o)
Date: Tue, 31 Oct 1995 11:52:56 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: 
Message-ID: <9510310316.AA26268@dcl.MIT.EDU>

   Date: Mon, 30 Oct 1995 21:59:14 -0500
   From: "Josh M. Osborne" 

   When /dev/random doesn't have "enough" enthropy left does reading
   from it return an error, or block?  I would strongly suggest
   blocking, as the non-blocking behavur is not really all that useful.

It acts like many character devices and named pipes in that if there is
no entropy available at all, it blocks.  If there is some entropy
available, but not enough, it returns what is available.  (A subsequent
read will then block, since no entropy will then be available.)

Actually, what's currently in Linux doesn't work precisely like this,
but it will soon.  After talking a number of people on both sides of the
block vs. non-blocking camp, this seemed to be a suitable compromise.
At least one Major Workstation Vendor is planning on using this behavior
for their /dev/random, to appear in a future OS release.  If we all can
standardize on this behavior, it'll make application writer's jobs that
much easier.

						- Ted

From rsalz at osf.org  Mon Oct 30 20:05:03 1995
From: rsalz at osf.org (Rich Salz)
Date: Tue, 31 Oct 1995 12:05:03 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
Message-ID: <9510310330.AA08343@sulphur.osf.org>

All your individual answers make sense.

Taken together, tho, they make HTTP-NG worrisome on the crypto front.

For example, it's probably a real bad idea to replace DES with something
commonly called RC4.  The former has been under public scrutiny for years,
the later still has not formally emerged from the shroud of trade secret.
The keyed MD5 responses also don't inspire confidence.

With all due respect, I strongly encourage you to leave crypto out of
HTTP-NG for the time being.  Wait to see what happens from the various
IPng security, SSL, S-HTTP, the W3C work, et cetera.  Leave some "holes"
in the protocol, but don't tie anything down now.  For better for the
Web to wait six to 12 months for HTTP-NG, then for mistakes to occur
in this area.
	/r$

From dlv at bwalk.dm.com  Mon Oct 30 20:36:02 1995
From: dlv at bwalk.dm.com (Dr. Dimitri Vulis)
Date: Tue, 31 Oct 1995 12:36:02 +0800
Subject: Cuban Security Conference
In-Reply-To: <199510301723.JAA22047@ix9.ix.netcom.com>
Message-ID: 

Bill Stewart  writes:
> >		International Conference Center
> >		     Pabexpo, Havana, Cuba
> >			March 4-9, 1996
> >	3rd Ibero-American Seminar on Protection against
> >    Computer Viruses and Security of Information Technologies
>
> I wonder if they'd be receptive to talks on private communications,
> digicash, tax avoidance through digital technology, anarchy and
> collapse of government power, etc. :-)

I don't know about the current situation, but back in the '80's, Cuba was
more high-tech than much of Eastern Europe.  I got an e-mail from Cuba
sent via the USSR and the Internet circa 1988; way before countries like
Poland or Romania had any sort of net.presence.

---

Dr. Dimitri Vulis
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

From hallam at w3.org  Mon Oct 30 20:54:37 1995
From: hallam at w3.org (hallam at w3.org)
Date: Tue, 31 Oct 1995 12:54:37 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510310330.AA08343@sulphur.osf.org>
Message-ID: <9510310427.AA28252@zorch.w3.org>

>For example, it's probably a real bad idea to replace DES with something
>commonly called RC4.  The former has been under public scrutiny for years,
>the later still has not formally emerged from the shroud of trade secret.
>The keyed MD5 responses also don't inspire confidence.

I disagree. Basically Simon simply has to stick in some parameters so that
the crypto alg can change with time. There should be slots for the following 
algs :-

Symmetric cipher	IDEA, RC4, 3DES
Keyed Digest		KD* (paper to follow, there are 7 to chose from).

Key exchange		Diffie-Helleman, El Gammal, RSA
Signature		RSA, El Gammal, Rabin (Shamir variation), DSS
Hash functions		MD5, SHA

I don't think that we are intending to tap Simons skill in designing 
ciphers. We have Ron Rivest and Taher El Gamal for that, plus help from
Adi Shamir and if we get stuck I'll bang on some other doors. I really don't 
think we have a problem lacking cryptographers. Simon is putting in security 
input which is different. We have an equally star studded cast for that side of 
things (and if we get stuck I'll e-mail some more characters).

	Phill

From tcmay at got.net  Mon Oct 30 20:59:02 1995
From: tcmay at got.net (Timothy C. May)
Date: Tue, 31 Oct 1995 12:59:02 +0800
Subject: Copy Protection Schemes
Message-ID: 

At 10:58 PM 10/30/95, Andrew Loewenstern wrote:

>IANAL, but I thought these types of laws were already tested and deemed
>unconstitutional in cases involving video-tape copying boxes, dual video
>cassette dubbing decks, SCMS 'scrubbers', etc...

The copy-defeat and SCMS scrubbers exist in a legal limbo, mainly being
sold for "other purposes" and often by companies which come and go in the
back pages of audio and video magazines.

For example, I've used a audio gadget (Audio Alchemy "DTI") that reclocks
the bit stream out of a digital source (CD or DAT player)...one of the side
effects is that it also strips (or resets, to be more precise) the SCMS
bits on a DAT recording. Effectively, it defeats the SCMS (Serial Copy
Management System) copy protection scheme. The company that makes it is of
coure well aware of this side effect, as is the audiophile/DAT community,
but the company (Audio Alchemy) takes great pains _not_ to mention this
side effect in their literature.

Likewise, the various Macrovision video copy protection scheme defeaters,
such as may be found in the back pages of video magazines, are "for the
legitimate user only."

I'm fairly certain that any open and aboveboard advertising of such
products as "copy protection defeaters" would face legal challenges under
the copyright laws.

The Go Video and other dual-cassette systems have ostensible legitimate
uses (notably, copying of tapes one has made, perhaps of lectures or
speeches or other personal recordings) and have been "allowed." In
particular, Go Video was held up in its plans for a couple of years while
lawyers and regulators negotiated.

Other cases, such as the Sony-Disney Betamax case, and, indeed, the Xerox
machine itself, involve other issues. Practicalities of enforcement are one
of the most important issues. The Supreme Court obviously looked at the
noninfringing uses (home movies, for example), the difficulty of enforcing
laws against the taping of television shows and movies, etc., and concluded
that technology and markets had made that particular aspect of copyright
law moot. The rationale of "time-shifting" was just the best face they
could put on it, in my view.

Anyway, there are lots of issues and lots of nuances.

--Tim May

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay at got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."

From rsalz at osf.org  Mon Oct 30 21:00:38 1995
From: rsalz at osf.org (Rich Salz)
Date: Tue, 31 Oct 1995 13:00:38 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
Message-ID: <9510310430.AA08480@sulphur.osf.org>

How are you going to handle mechanism negotiation?

From mark at grondar.za  Mon Oct 30 22:32:45 1995
From: mark at grondar.za (Mark Murray)
Date: Tue, 31 Oct 1995 14:32:45 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510310612.IAA03091@grumble.grondar.za>

> When /dev/random doesn't have "enough" enthropy left does reading
> from it return an error, or block?  I would strongly suggest
> blocking, as the non-blocking behavur is not really all that useful.

It returns EOF.

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From jsw at netscape.com  Mon Oct 30 22:41:38 1995
From: jsw at netscape.com (Jeff Weinstein)
Date: Tue, 31 Oct 1995 14:41:38 +0800
Subject: CJR returned to sender
In-Reply-To: 
Message-ID: <3095BF32.2A72@netscape.com>

Timothy C. May wrote:
> 
> At 4:43 PM 10/26/95, Jeff Weinstein wrote:
> 
> >  The ITARs are currently keeping us(Netscape) from distributing
> >our US-only products to people within the United States.  We have
> >asked for clarification from the government about network distribution,
> >such as how much verification of location and citizenship of the
> >recipient we must do, and have yet to receive a response.  That
> >makes it more than just an export issue, at least for us.
> 
> And I agree that this is a much more important issue than whether a t-shirt
> can get an OK for export or not.
> 
> If the CJR for the t-shirt is ultimately granted, what useful information
> will be derived, or what implications for Netscape's question will be
> discovered?
> 
> If the CJR for the t-shirt is ultimately denied, ditto?

  It will force the bureaucrats to make a decision, which will be
the subject to much public scrutiny.  Hopefully it will generate a
stir in the press and inform many more people of the problems of
the current system.

	--Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw at netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

From klp at gold.tc.umn.edu  Mon Oct 30 23:05:54 1995
From: klp at gold.tc.umn.edu (Kevin L Prigge)
Date: Tue, 31 Oct 1995 15:05:54 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: 
Message-ID: <3095c7353a43002@noc.cis.umn.edu>

According to rumor, Doug Hughes said:
> >  Since you deal with security issues maybe you can help me to learn 
> >about some issues with encryption.  I am talking with one of the 
> >administration people about putting PGP on the system for everyone to 
> >use, but there are issues for them (the admin) as they might be liable, 
> >even if they can't read the e-mail.  What other legal considerations 
> >should be evaluated?
> >  Is there any large organizations (like any other universities) that 
> >allow their students to use PGP, and have the system in place to make it 
> >easier for the students?  If it is offered here I might be the one to add 
> >to the mail program (pine) that is generally used to transparently use 
> >PGP, which is what I mean by having a system set up for the encryption. 
> >  Thanx for any help.  Take care and have fun.
> >
> >James Black
> >black at suntan.eng.usf.edu
> >
> >
> We have approx 1000 machines and 5000 user accounts and have pgp installed.
> I can't think of any reason not to have it installed, and lots of good
> reasons for having it installed.

We currently have PGP installed on our 2 central email servers that
have approximatly 20,000 users. We haven't integrated it at this
point into Pine, etc mostly due to time and resources. 

I don't know why inability to read e-mail would cause liability,
and moving 2 million messages a week, I don't think that anyone
could be expected to know what users are sending. We only respond
to complaints.

-- 
Kevin Prigge                        |  Holes in whats left of my reason, 
CIS Consultant                      |  holes in the knees of my blues,
Computer & Information Services     |  odds against me been increasin' 
email: klp at cis.umn.edu              |  but I'll pull through...  

From fen at comedia.com  Mon Oct 30 23:44:16 1995
From: fen at comedia.com (Fen Labalme)
Date: Tue, 31 Oct 1995 15:44:16 +0800
Subject: FWD: Electronic Warfare (from the digitaliberty list)
Message-ID: <199510310725.XAA06543@imagine.comedia.com>

Interesting (if a bit mild for this list) article from another list some of
you might be interested in (or already subscribed to)....

---- Forwarded Message ----

From: owner-digitaliberty at phantom.com
Date: Tue, 31 Oct 1995 01:00:06 -0500
To: digitaliberty-digest at piltdown.phantom.com
Subject:   digitaliberty V1 #13

digitaliberty             Tuesday, 31 October 1995      Volume 01 : Number 013

In this issue:

Test
Electronic Warfare

See the end of the digest for information on subscribing to the Digitaliberty
or Digitaliberty-Digest mailing lists.

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

From: Bill Frezza (via RadioMail) 
Date: Mon, 30 Oct 1995 13:14:58 -0800
Subject: Test

This is a test. 

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

From: DigitaLib at aol.com
Date: Mon, 30 Oct 1995 18:02:17 -0500
Subject: Electronic Warfare

Folks,

Attached is a column that ran on the op-ed page of today's Communications
Week. I have agreed to do bi-weekly opinion pieces for them focussing on the
impact of technology on society, politics, and culture - all with a
DigitaLibertarian slant (of course). My hope is that this fiesty group can
keep me fed with grist for these pieces.

For anyone that lives in NYC, I will be carrying the DigitaLiberty banner on
a panel on digital commerce at the Multimedia Design conference at the Javits
center Friday 11/3 at 3:30pm. Stop by and say hello.

Regards,

Bill

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

ELECTRONIC WARFARE WAGES ON - AND YOU'RE THE TARGET

Although the flap over the Clinton administration's attempt to promote
escrowed-key encryption systems like Clipper has temporarily faded, the war
on electronic privacy continues.   As proceedings at the Fourth International
Conference on Money Laundering, Forfeiture, Asset Recovery, Offshore
Investments, the Pacific Rim, and International Financial Crimes reveal,
there has been no let up in our government's efforts to blockade the
cyber-frontier.

No, you won't learn much from the Wall Street Journal or the New York Times,
written by journalist-generalists who have no clue about where this
technology is heading.  The Feds have become so skilled at manipulating the
Old Media that stories about electronic privacy  invariably center on the
latest drug kingpin, pedophile, or domestic terrorist.  Attacking these
universally abhorred enemies of the people not only makes for good headlines
but keeps privacy advocates off balance as they are forced to defend abstract
rights using loathsome examples.  But if you tune in to the Cypherpunks
mailing list (majordomo at toad.com) you can get some excellent first hand
reports from the front.

In the relatively short period since the passage of the Bank Secrecy Act,
which, among other things, obliges banks to file Suspicious Activity Reports
on its customers, banks have become virtual deputies in the treasury
department's war on uncontrolled financial transactions.  And this war is
increasingly spilling into cyberspace.

The conference underscored the fact that, paradoxically, we are heading not
toward more specific and well defined transaction monitoring regulations, but
less.  How so?  The problem with making regulations precise is that what
software algorithms can define, other algorithms can evade.  Instead,
regulation by "raised eyebrow" is becoming the norm.  Federal bank examiners
have been given significant latitude to invoke draconian penalties against
uncooperative banks.  Because bank officers have few due-process protections
under this regime, it is no surprise that most of them have become sniveling
toadies.  The objective is to insure that banks "voluntarily" introduce even
more aggressive, unpredictable, and intrusive monitoring than the government
would ever dare mandate.  And to make sure nothing slips through the cracks,
human surveillance will be supplemented with artificial-intelligence agents
that can perform pattern analysis on the aggregate flow of electronic
transactions, flagging anything remotely suspicious.  George Orwell would be
impressed.

Lest you think that all of this is motivated solely by the drug war,  a visit
to the Treasury Department's Financial Crimes Enforcement Network (FinCEN)
homepage (http://www.ustreas.gov/treasury/bureaus/fincen/facts.html) should
open your eyes.  This battle is not just about drug prohibition, a crime the
Treasury Department would have to invent if it didn't already exist.  The
real struggle is about the future of tax compliance, and it has you in its
sights.

A famous Revolutionary War era pamphleteer, writing under the pseudonym
"Brutus", perhaps said it best 200 years ago when he wrote - "The national
government through its taxing power will introduce itself into every corner
of the city and country.  It will take cognizance of the professional man in
his office or his study;  it will watch the merchant in his store;  it will
follow the mechanic to his shop and his work, and will haunt him in his
family and his bed;  it will be the constant companion to the industrious
farmer in his labour;  it will penetrate into the most obscure cottage;  and
finally it will light upon the head of every person in the United States.  To
all these different classes of people and in all these circumstances on which
it will attend them, the language in which it will address them will be GIVE!
GIVE!"

What Brutus didn't know and what the cypherpunks foresee is that one day
strong encryption will make it impossible to spy on our activities in
cyberspace.  Heightened conflict is inevitable.  Expect the rhetoric to get a
lot hotter as the government spinmeisters labor to keep us focused on public
enemies while frantically trying to keep its hand in every citizens pocket
and its eyes on every bankbook. 

# # #
COPYRIGHT CMP PUBLICATIONS 1995

Bill Frezza is president at Wireless Computing Associates and co-founder of
the online forum DigitaLiberty.  The opinions expresses are his own. Frezza
can be reached at frezza at interramp.com.

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

End of digitaliberty V1 #13
***************************

To subscribe to Digitaliberty-Digest, send the command:

subscribe digitaliberty-digest

in the body of a message to "Majordomo at phantom.COM".  If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-digitaliberty":

subscribe digitaliberty-digest local-digitaliberty at your.domain.net

A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "digitaliberty-digest"
in the commands above with "digitaliberty".

---- End Forwarded Message ----

From aleph1 at dfw.net  Mon Oct 30 23:58:12 1995
From: aleph1 at dfw.net (Aleph One)
Date: Tue, 31 Oct 1995 15:58:12 +0800
Subject: Using Holographic Memory Crystals for Encryption
Message-ID: 

*WARNING*
I have not idea about what Iam about to talk.
This is a midnight rant. Take it as it is.
*WARNING*

I just finished reading the article on Holographic Memories on the latest
Scientific America by Demetri Psaltis and Fai Mok. At the end they 
mention that "Given a hologram, either one of the two beams that 
interfered to create it can be used to reconstruct the other. What this 
means, in a holographic memory, is that it is possible not only to orient 
a reference beam into the crystal at a certain angle to select an 
individual holographic page but also to accomplish the reverse. 
Illuminating a crystal with one of the stored images gives rise to an 
approximation of the associated reference beam, reproduced as a plane 
wave emanating from the crystal at the appropriate angle."

	I was thinking this is simply a kind of XOR here given one image 
you can obtain the other. No this convined with the fact that you need
to know the right angle could make for some interesting stuff. You could 
make a system where you give it the initial angle and password which is 
illuminated into the cristal to reveal the encoded data add to this some 
feadback mechanism where the angle changes depending on some function of 
the data and things get interesting.

	Its late and Iam tired. But if anyone has any ideas I woulkd love 
to heard them. Good nite.

Aleph One / aleph1 at dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 

From aleph1 at dfw.net  Tue Oct 31 00:17:24 1995
From: aleph1 at dfw.net (Aleph One)
Date: Tue, 31 Oct 1995 16:17:24 +0800
Subject: Digicash on Scientific American
Message-ID: 

Another thing before I go to bed. On the November issue of Scientific 
American the Essay column writen by Anne Eisenberg is titled "Doing 
Busioness on the Net". Its short (one page), but metions PK crypto, 
touches upon the dangers that online transcations pose to privacy, and 
talks a bit about ecash. Sadly there is no mention of ITAR *sight*

Aleph One / aleph1 at dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 

From anon-remailer at utopia.hacktic.nl  Tue Oct 31 18:35:18 1995
From: anon-remailer at utopia.hacktic.nl (Anonymous)
Date: Tue, 31 Oct 95 18:35:18 PST
Subject: "Dr." Fred
Message-ID: <199511010235.DAA00908@utopia.hacktic.nl>

The most charitable explanation for "Dr." Fred is that
he's degenerated into the professional equivalent of
those pathetic aging former chess masters who try to
eek out a subsistence living by charging five bucks a
game. People often play with them out of sympathy, or
for the novelty of having lost to a past great. It's
part of the chess culture, and it's basically harmless
and sort of quaint.

The difference, of course, is that its almost impossible
to have sympathy for Dr. Fred. His hustle is for a hell
of a lot more than subsistence. He was also never actually
a master of his field, a fact that becomes increasingly
obvious as our exposure to him goes on. Now he's reduced
himself to trying to collect someone else's winnings.

From cjs at netcom.com  Tue Oct 31 18:55:34 1995
From: cjs at netcom.com (Christopher J. Shaulis)
Date: Tue, 31 Oct 95 18:55:34 PST
Subject: IBM's Microkernal
In-Reply-To: <199511010122.CAA29490@utopia.hacktic.nl>
Message-ID: <199511010154.UAA00189@localhost.cjs.net>

> The Wall Street Journal, October 31, 1995, p. B6. 
> 
> IBM Announces New Software Code That Is Universal
> 
> By Laurie Hays
> 
> International Business Machines Corp., in its effort to reduce
> the importance of computer-operating systems, announced a new
> kind of universal-software code called Microkernal that
> enables software to work on incompatible hardware.

Oh Jesus.. now I've seen everything.

Bring forth the holy clue-gernade!

Christopher

From stewarts at ix.netcom.com  Tue Oct 31 19:20:08 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Tue, 31 Oct 95 19:20:08 PST
Subject: Important Digital Cash Question...
Message-ID: <199511010319.TAA15603@ix8.ix.netcom.com>

>>I think that the bankers name should be Ethel however.
>Wait, wait! I have another one. I call digital cash bankers "underwriters",
>because they're basically underwriting digital certificates, like an
>underwriter in the capital markets does.
>So, we need a "U" name...

Obviously Alice and Bob are banking with Chaum....
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From stewarts at ix.netcom.com  Tue Oct 31 19:21:19 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Tue, 31 Oct 95 19:21:19 PST
Subject: ecash remailer
Message-ID: <199511010321.TAA15848@ix8.ix.netcom.com>

Sameer and Hal both suggested ecash-laundering methods to provide 
payee anonymity using methods like this:
>Enterprising cypherpunk, Ed sets up the Ecash Remailer.
>Alice pays Bob e$15. Alice is anonymous.
>Bob sends Ed the e$15
>Ed cashes the e$ into his ecash mint account, withdraws e$13.50
>then pays Bob those e$14 .. Bob can now spend those e$ at will.
>	Bob is now anonymous.

As implemented here, Ed is strictly in the money-laundering businesss,
and can expect a visit from the Feds as soon as they can break through
the chain of digital mixes and crypto he uses to operate alt.money.laundry,
or follow the money when _he_ tries to deposit it.  On the other hand,
he could operate a strictly legitimate business, selling financial assets 
such as bearer bonds or low-commission lottery tickets, or converting
funds between different e-banks, or simply offering anonymous bank accounts
with currencies in multiple denominations - Bob can set up an account
with Ed's Eurocurrency Exchange in the name "Public Key nnnnn",
deposit his $15, and withdraw US$14.95 worth of Yen or Deutschmarks or
Kongbucks.

Aside from Bob's need to trust Ed, and his need to trust Alice not to
double-spend (since laundering used bills is much harder than laundering
marked bills) it first looked to me like Ed has a serious risk that he'd
be nabbed by the Feds as soon as he tried to spend the bills, so he has
to trust Bob not to be spending ransom money or pharmaceutical profits.

But as near as I can tell, _any_ merchant has that risk, because there's
no way for Ed to distinguish between cash that Bob withdrew himself
and cash that Bob got from someone else.  Does this mean that anybody
who sells goods to anonymous clients is automatically a money-launderer?
If so, either the bogus money-laundering laws have to go (yay!) 
or laws against selling to anonymous clients will get written (boo!) 
or selective enforcement and entrapment will become increasingly popular, 
leading merchants to refuse to do anonymous business just to defend themselves
against extortionists\\\\\\\\\\\\legitimate needs of law enforcement?
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From rah at shipwright.com  Tue Oct 31 19:21:35 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Tue, 31 Oct 95 19:21:35 PST
Subject: Internet World Boston
Message-ID: 

David Fox has me on a panel discussion he's leading tomorrow (November 1)
at Internet World in Boston in the Harborview Ballroom from 10:15 to 12:30.

Also on the panel will be someone each from First Virtual, Open Market, and
CheckFree, all of whom will be demo-ing their latest stuff. This promises
to be interesting, and it would also be a great opportunity for me to
actually meet some people I only read in e-mail.

If you're around, I hope to see you there!

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah at shipwright.com)
Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
USA (617) 323-7923
"Reality is not optional." --Thomas Sowell
>>>>Phree Phil: Email: zldf at clark.net  http://www.netresponse.com/zldf <<<<<

From stewarts at ix.netcom.com  Tue Oct 31 19:22:00 1995
From: stewarts at ix.netcom.com (Bill Stewart)
Date: Tue, 31 Oct 95 19:22:00 PST
Subject: PGP at Universities
Message-ID: <199511010321.TAA15856@ix8.ix.netcom.com>

At 04:37 PM 10/30/95 -0600, James Black black at suntan.eng.usf.edu wrote:
>>I am talking with one of the 
>>administration people about putting PGP on the system for everyone to 
>>use, but there are issues for them (the admin) as they might be liable, 
>>even if they can't read the e-mail.  What other legal considerations 
>>should be evaluated?
>>  Is there any large organizations (like any other universities) that 
>>allow their students to use PGP, and have the system in place to make it 
>>easier for the students?  If it is offered here I might be the one to add 
>>to the mail program (pine) that is generally used to transparently use 
>>PGP, which is what I mean by having a system set up for the encryption. 

Well, one obvious example is MIT, which not only makes PGP available to
its students, it makes it available to everyone else in the US,
though ostensibly not everyone else in the world.  Your University isn't
required to be reading students' and employees' private email anyway,
(though it can get away with it by announcing it as official policy),
so not being able to read it because of PGP is just fine - if anything it
may reduce their legal liability by offering students the option of having
truly private email, where sysadmins won't even be able to read bouncemail
or other fragments of messages left around when mailers break.

On the other hand, I'm guessing that usf.edu is in the USA?  If so, 
there may be ITAR considerations - are any of your students non-US citizens
without Green Cards?  Offensive as it sounds, it may not be legal to let
them use a copy of PGP that you provide (though it's perfectly legal for
them to import copies from the UK for their own use.)  There _are_ privacy-
protecting programs you can let them use, such as the next edition of Netscape,
which has 40-bit RC4, and you can use digital signatures from packages like
RIPEM-SIG, which is a signature-only subset of RIPEM that's approved for export.
Since Netscape 2 will be using X.509 certifications, which RIPEM uses,
you or your students can do things like building good friendly user interfaces
to the current character-menu certification chains that RIPEM provides
(somewhat like PGP's Web of Trust, but a bit clumsier for now.)
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts at ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---

From ddt at digicash.com  Tue Oct 31 19:23:43 1995
From: ddt at digicash.com (Dave Del Torto)
Date: Tue, 31 Oct 95 19:23:43 PST
Subject: W3 Self-Regulation?
Message-ID: 

[Where's Tipper when you need her? Answer:]

FOR IMMEDIATE RELEASE

Contact:   Ron Warris, President, Internet Filtering Systems, Inc.
phone:     1-403-258-5804, email: warrisr at colt.t8000.com
Web:       www.tenagra.com/ifsi

DEMOCRATIC WORLD-WIDE WEB SELF-REGULATION ANNOUNCED

CALGARY, ALBERTA, CANADA -- October 30, 1995 -- Internet Filtering Systems,
Inc. (IFSI) today announced Net Shepherd, the first product designed to
democratically rate and filter World Wide Web sites and selectively
supervise access.

Net Shepherd is the first PICS-compliant rating and filtering solution.
Under the auspices of The World Wide Web Consortium, PICS (Platform for
Internet Content Selection) is a cross-industry working group whose goal is
to facilitate the development of technologies to give users control over
the kinds of material to which they and their children have access.

According to Ron Warris, president of IFSI, "There are a number of
companies offering filtering solutions. What is really needed is a rating
solution. How do you go about reviewing and rating 8.5 million volatile
documents on the Internet? Our approach will allow the people who surf the
Internet to be the people who rate the Internet. With Net Shepherd,
parents, educators and other concerned organizations will be able to
voluntarily participate in the rating process.

Mr. Warris continues, "Net Shepherd will also provide parents with the
ability to selectively filter documents viewed by their children. Parents
can choose from a variety of rating databases that represent the
accumulated ratings from others who hold similar views and philosophies.
Organizations that wish to create rating databases for their subscribers
will also be able to use Net Shepherd. You'll be able to subscribe to the
Good Housekeeping database or the Lutheran Church database or the ACLU
database. Take your pick.

"The Internet has always been self-regulating and special-interest-group
oriented. Now the World Wide Web can be as well."

IFSI's mission is to become the preferred and premier provider of Internet
rating systems and services for individual consumers, concerned groups and
associations, as well as other filter software developers. A World-Wide Web
site currently contains basic information about IFSI, and will evolve over
the coming weeks into an extensive resource for those interested in
Internet content filtering. It is located at URL

>From the Web page:

Internet Filtering Systems, Inc. is the developer of Net Shepherd, the
first product designed to democratically rate and filter World Wide Web
sites and selectively supervise access. The Internet has always been
self-regulating and special-interest-group oriented. Now the World Wide Web
can be as well.

Net Shepherd is the first PICS-compliant rating and filtering solution.
Under the auspices of The World Wide Web Consortium, PICS (Platform for
Internet Content Selection) is a cross-industry working group whose goal is
to facilitate the development of technologies to give users control over
the kinds of material to which they and their children have access.

Net Shepherd allows the people who surf the Internet to be the people who
rate the Internet. With Net Shepherd, parents, educators and other
concerned organizations will be able to voluntarily participate in the
rating process. Net Shepherd will also provide parents with the ability to
selectively filter documents viewed by their children. Parents can choose
from a variety of rating databases that represent the accumulated ratings
from others who hold similar views and philosophies. Organizations that
wish to create rating databases for their subscribers will also be able to
use Net Shepherd.

IFSI's mission is to become the preferred and premier provider of Internet
rating systems and services for individual consumers, concerned groups and
associations, as well as other filter software developers.

[cf. PICS (Platform for Internet Content Selection) at
  ]

From madden at mpi-sb.mpg.de  Tue Oct 31 04:33:52 1995
From: madden at mpi-sb.mpg.de (Peter Madden)
Date: Tue, 31 Oct 1995 20:33:52 +0800
Subject: Turing Award
Message-ID: <199510311219.NAA02181@mpii02024.ag2.mpi-sb.mpg.de>

Hi All,

Further to previous cypherpunk discussions on cryptography, and on program
checking/verification, the below announcement of this years Turing Award
should be of interest (apologies if this is old news).

Pete

=================================================================

Dr Peter Madden,                                Email: madden at mpi-sb.mpg.de
Max-Planck-Institut fuer Informatik,            Phone: (49) (681) 302-5434
Im Stadtwald, W-66123 Saarbruecken, Germany.    Fax: (49) (681) 302-5401

=================================================================

----- Begin Included Message -----

>From seidel at cs.uni-sb.de Thu Oct 26 08:57:10 1995
Date: Thu, 26 Oct 1995 08:57:02 +0100
From: seidel at cs.uni-sb.de (Raimund Seidel)
To: profs at sol.cs.uni-sb.de
Subject: Turing Award
Content-Length: 4661

------- Forwarded Message

ACM'S A.M. Turing Award, computing's highest honor, goes to
Manuel Blum of University of California, Berkeley
Date: Saturday, October 21, 1995 3:55PM

BW1320  OCT 20,1995      15:22  PACIFIC      18:22  EASTERN

( BW)(ACM/TURING-AWARD/BLUM) ACM'S A.M. Turing Award, computing's
highest honor, goes to Manuel Blum of University of California, Berkeley

    Business Editors

    NEW YORK--(BUSINESS WIRE)--Oct. 20, 1995--Considered the Nobel
Prize of Computing, the A. M. Turing Award of the Association for
Computing Machinery (ACM), will be given to distinguished computer
scientist, Manuel Blum, of the University of California, Berkeley.
The award will be presented to Blum at a special awards ceremony
during the kick off of ACM's yearlong 50th anniversary celebration,
February 14-18, 1996 in Philadelphia.
    Blum was honored with the Turing Award "in recognition of his
contributions to the foundation of computational complexity theory
and its applications to cryptography and program checking."
computing devices, Blum's research has developed around a single
unifying theme: finding positive, practical consequences of living in
a world where all computational resources are bounded.  Blum shows
that secure business transactions, pseudo-random number generation,
and program checking are all possible precisely because all
computational devices are resource bounded.
    Blum is one of the founders of computational complexity theory, a
field that is central to theoretical computer science, and one which
deals with measuring the difficulty of performing computations.  His
work on machine-independent complexity yields a theory of
computational cost that is relevant also to practical problems.
Cryptographic protocols which are used in the transmission of
sensitive information are secure because they can be shown to be
information in a cryptographically encoded message without going
through an inordinately complex computation that would be
prohibitively costly and time consuming to perform.  For computer
programs it is very difficult to develop perfectly error-free
programs.  In this area Blum has shown how his techniques can be
applied to make programs more reliable, and to check their results.
Since this work is very fundamental one can expect that it will find
application to many other practical problems, as well.
    "Manuel Blum is a profound thinker,"  said ACM President Stuart
H. Zweben, chairman of the department of computer and information
science at Ohio State University, "his seminal work, insights and
approaches have brought about new avenues of research in the area of
computational complexity and established foundations for what people
can compute.  Furthermore, his work has influenced other Turing Award
winners to a significant degree."
    The ACM A. M. Turing Award is given annually for technical
achievements in the field of computing which are deemed by a jury of
leading professionals to be of lasting and significant importance to
the computing community.  It is accompanied by a prize of $25,000
contributed by AT&T.
    Dr. Blum is University of California at Berkeley's Arthur J.
Chick Professor in Electrical Engineering and Computing Sciences, a
Department in which he has served since 1968.  Dr.  Blum was born in
Caracas, Venezuela in 1938 and began his academic career at the
Massachusetts Institute of Technology, where he received his B.S.,
Warren S. McCulloch, Hartley Rogers Jr. and Marvin Minsky.  Dr.
Blum is renowned for his work on computational complexity, automata
theory, inductive inference, cryptography and program
result-checking.  During his career, Dr.  Blum has received numerous
awards, published 47 technical papers and advised 26 Ph.D.  students.
    ACM, founded in 1947, is an 85,000 member international
scientific and educational organization dedicated to advancing the
art, science, engineering and application of information technology.
ACM serves both professional and public interests by fostering the
open interchange of information and by promoting the highest
professional and ethical standards.  This is accomplished through its
many publications, conferences, special interest groups, chapters and
network communications.

    --30---rg/ny*

    CONTACT: Terrie Phoenix
             (212) 626-0531
             phoenix at acm.org
    KEYWORD: NEW YORK
    INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS COMED

REPEATS: New York 212-575-8822 or 800-221-2462; Boston 617-236-4266 or
         800-225-2030; SF 415-986-4422 or 800-227-0845; LA 310-820-9473
     BW URL: http://www.hnt.com/bizwire

------- End of Forwarded Message

----- End Included Message -----

From nobody at REPLAY.COM  Tue Oct 31 06:15:13 1995
From: nobody at REPLAY.COM (Anonymous)
Date: Tue, 31 Oct 1995 22:15:13 +0800
Subject: Smart Snoops
Message-ID: <199510311348.OAA13053@utopia.hacktic.nl>

Wall Street Journal, October 30, 1995, p. B3.

Netcom to Use Smart Switches For the Internet

By Audrey Choi

Internet provider Netcom On-Line Communication Services Inc.
said it will use high-speed network switches from Cascade
Communicaffons Corp. in a move to upgrade the speed and
flexibility of its Internet services.

Netcom's decision represents a significant endorsement for
Cascade, a small Westford, Mass.-based company whose revenues
have soared along the rapid growth of the Internet. In
addition to Netcom, Cascade also is supplying switching
devices, which control the flow of information across a
far-flung computer network, to UUNet Technologies Inc. and
Performance Systems International Inc.

To prepare for an expected rise in the number of users,
networking analysts say the Internet needs to move toward a
more efficient architecture based on high-speed intelligent
switches, like Cascade's, which not only allow large volumes
of data to be transmitted quickly, but also offer Internet
service providers the ability to track and manage the data
being transported.

Brad Meinert, senior analyst at research firm Input, says the
tremendous growth of the World Wide Web, a graphics Internet
interface, "is putting increased capacity demands for greater
bandwidth on the Internet infrastructure."

In the past, the Internet depended primarily on simpler
router-based wide-area networks that provided access to users
with dial-up modems and leased lines. Bundles of data moving
over this kind of network is evaluated and processed at each
router until it arrives at its destination -- a tedious
process that can adversely affect time-sensitive applications,
such as video conferencing.

"We've been talking about an information super highway, but
our infrastructure is really just dirt roads," said Daniel E.
Smith, Cascade's president and chief executive. Mr. Meinert
noted that "switching is clearly the next generation, which
allows you to create the virtual network."

Financial details of the Netcom deal weren't disclosed, but
Cascade's Mr. Smith said the deals with the three major
Internet providers initially represents "tens of millions of
dollars" of business. UUNet said it has purchased $6.5 million
worth of Cascade products.

Cascade's switches provide the highest port density and
highest network capacity, analysts say. Its switches range in
cost from $25,000 to $250,000 and enable a far greater number
of users to access the Internet through any one point. While
a typical router may be able to handle 20 to 50 users, a
single Cascade switch can accommodate 1,000 users, says Desh
Deshpande, Cascade's founder and marketing vice president.
Additionally, the management capabilities of the smart
switches enable Internet providers to track how many data
bundles a customer sends, where each bundle is at any point in
time, and what priority on the network they should be given.

-----

From nobody at REPLAY.COM  Tue Oct 31 06:22:07 1995
From: nobody at REPLAY.COM (Anonymous)
Date: Tue, 31 Oct 1995 22:22:07 +0800
Subject: Virtual Security Jitters
Message-ID: <199510311351.OAA13151@utopia.hacktic.nl>

Financial Times, October 30, 1995, p. 13.

Online bank era dawns

By Louise Kehoe

The Security First Network Bank established by Cardinal
Bancshares -- a small Kentucky savings and loan institution is
the first financial institution to conduct true online banking
over the Internet.

SFNB's pioneering effort may influence the growth of Internet
banking. Larger financial institutions are watching for clues
as to how consumers respond and to see whether the cyberbank
can live up to its "Security First" name.

Concerns about Internet security exacerbated by incidents in
which supposedly secure software has proven vulnerable -- have
made banks cautious. SFNB claims to have created a "virtual
vault" for each customer account, using a "trusted" computer
operating system from Hewlett-Packard the second largest US
computer company, as well as encryption and user
authentification software, and firewalls.

"We have overcome the problem that has prevented banks from
transacting over the Internet," said James Mahan, SFNB's
chairman.

Perhaps cyberbanking's biggest draw is that the SFNB is open
24 hours a day, seven days a week. Customers will be able to
conduct standard personal banking tasks such as paying bills,
transferring funds from one account to another and checking
the balance of an account.

Nor are there queues at the counters in the "virtual lobby" of
the SFNB which are staffed by computer renditions of
R2D2-style robots (http://www.sfnb.com).

But waiting for images to download from the Internet over a
modem may persuade users that a bus trip to their local bank
is not such a bad idea.

SFNB also faces competition from more than 20 US banks
including Chemical Bank, Wells Fargo and First Interstate that
have formed partnerships with Intuit, the leading personal
finance software company, to enable users of the popular
Quicken program to access information from their accounts and
pay bills electronically.

Services offering stock prices, information about mortgages,
loans and retirement funds as well as insurance are
flourishing.

Some of the most innovative include BankAmerica's new Web site
which opened a week ago with an invitation to users to "build
your own bank". By filling in a form, users can tailor the
information presented to fit their interests.

A student, for example, might be presented with information
about obtaining loans for college fees. Someone close to
retirement age would automatically be routed to information
more relevant to his interests.

One of the largest mortgage lenders in the US, Bank of
America, has also chosen to put an emphasis on property
purchases at its Web site.

Hyperlinks to real estate firms throughout the US enable users
to search through lists of homes for sale and then to link
back to the bank in order to apply for financing
(http://www.bankamerica.com).

Among the biggest attractions of the Internet for consumers,
including consumers of financial services, is the ability to
"shop around" so as to compare costs and advantages.

The insurance industry is taking this to heart in a new
service that goes live today. Insweb will enable consumers to
seek quotes from a range of companies and brokers on life,
home, car and medical insuranee.

The service, established by a group of 25 insuranee companies
and related organisations is the first "marketplace" on the
Internet for insurance information and commerce.

Insweb plans to enable users to purchase insurance online. In
a pilot program next month, residents of the state of Utah
will be able to buy car insurance via the Internet
(http://www.insweb.com).

-----

Internet Law Review is a monthy paid-for publication available
electronically or on hard copy from December. Among other
issues, it will cover IT-law and the Internet; commercial
security and encryption, using contributors from North America
and Europe. Subscription is $220 a year and details are
available from . Meanwhile,
details of this week's Internet Law Symposium in Seattle are
available at .

-----

From jamesd at echeque.com  Tue Oct 31 07:34:06 1995
From: jamesd at echeque.com (James A. Donald)
Date: Tue, 31 Oct 1995 23:34:06 +0800
Subject: CJR returned to sender
Message-ID: <199510311509.HAA23755@blob.best.net>

At 10:16 PM 10/30/95 -0800, Jeff Weinstein wrote:
>  It [CJR application for T shirts] will force the bureaucrats 
> to make a decision, 

You cannot force bureaucrats to make a decision.

They will act if it suits their purpose, and otherwise they
will not act.

Basic of principle of strategy in Go:  If you give the other 
guy choices, you will lose.  That is why go players always 
play asymmetrically if the stones are symmetric.

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

From hfinney at shell.portal.com  Tue Oct 31 08:13:47 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 1 Nov 1995 00:13:47 +0800
Subject: payee anonymity
Message-ID: <199510311535.HAA05408@jobe.shell.portal.com>

Another way payees could be anonymous would be to immediately spend their
received coins, and do so anonymously.  This works for the online ecash
system.  They simply pass the coins on without first exchanging them at
the bank.  There would have to be something they wanted to buy that they
could receive anonymously, though.

Hal

From jamesd at echeque.com  Tue Oct 31 08:52:59 1995
From: jamesd at echeque.com (James A. Donald)
Date: Wed, 1 Nov 1995 00:52:59 +0800
Subject: Cuban Security Conference
Message-ID: <199510310707.XAA17024@blob.best.net>

At 01:22 PM 10/30/95 -0500, s1113645 at tesla.cc.uottawa.ca wrote:
> For that matter is civilian use of strong (or any other kind) crypto actually
> legal in Cuba? Anyone know the policies? (duh, lemme guess...)

Well everything is legal in Cuba since there are no discernable laws, only
policies, however at they time that I visited Cuba those phones available
to ordinary citizens had a phonekeeper seated right beside the phone.

On the other hand, no one would stop you setting up a data haven or
some such in Cuba, provided it was strictly off limits to Cubans, 
but you could not set up a bank, because sooner or later somebody 
quite important would help themselves to the banks assets.

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

From walrus at ans.net  Tue Oct 31 10:12:43 1995
From: walrus at ans.net (michael shiplett)
Date: Wed, 1 Nov 1995 02:12:43 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510302351.AA28243@zorch.w3.org>
Message-ID: <199510311647.LAA01071@fuseki.aa.ans.net>

"h" == hallam   writes:

h> There is some work by Phil Rogaway on making keyed digest
h> functions which I strongly recommend people look at. I can post a
h> paper on the subject if people are interested.

There's also ``Message Authentication with MD5'' by Burt Kaliski and
matt Robshaw in RSA Laboratries' CryptoBytes,
http://www.rsa.com/rsalabs/cryptobytes/spring95/md5.htm,

michael

From sameer at c2.org  Tue Oct 31 10:17:21 1995
From: sameer at c2.org (sameer)
Date: Wed, 1 Nov 1995 02:17:21 +0800
Subject: ecash remailer
Message-ID: <199510311625.IAA07105@infinity.c2.org>

To provide payee anonymity:

Enterprising cypherpunk, Ed sets up the Ecash Remailer.

Alice pays Bob e$15. Alice is anonymous.
Bob sends Ed the e$15
Ed cashes the e$ into his ecash mint account, withdraws e$13.50
then pays Bob those e$14 .. Bob can now spend those e$ at will.

	Bob is now anonymous.

	This requires some trust-in-Ed, but Bob could be anonymous
from Ed just as Ed is anonymous.

	Perhaps this is the scheme lucky mentioned. I will have to get
an account and implement it.

-- 
sameer						Voice:   510-601-9777
Community ConneXion				FAX:     510-601-9734
The Internet Privacy Provider			Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer at c2.org

From lull at acm.org  Tue Oct 31 10:22:27 1995
From: lull at acm.org (John Lull)
Date: Wed, 1 Nov 1995 02:22:27 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510310427.AA28252@zorch.w3.org>
Message-ID: <199510311650.IAA09144@ix2.ix.netcom.com>

On Mon, 30 Oct 1995 23:27:36 -0500, you wrote:

> Hash functions		MD5, SHA

I presume you mean SHA-1.

I would prefer to see MD5 deleted.  A 128 bit hash simply seems too
marginal in length for long term use in most hash applications.  I
would much rather see something like Haval as a second hash algorithm.
It can be faster than MD5, and can easily be tailored to the hash
width you want.  If 128 bit hashes are really needed, use Haval's
128-bit option.

From mark at unicorn.com  Tue Oct 31 10:38:17 1995
From: mark at unicorn.com (Rev. Mark Grant)
Date: Wed, 1 Nov 1995 02:38:17 +0800
Subject: ecash remailer
Message-ID: 

On Tue, 31 Oct 1995, Hal wrote:

> Also, I believe in normal use Digicash coins are marked as being for a
> specific recipient.  This is not certain since no details have been
> released.  And apparently it can be worked-around by the spender by
> marking the recipient as just "@" (or some such string).

Yep, it's optional. You can specify the account id of the recipient, in 
which case it's encrypted into the ecash message somehow, or you can 
leave it blank, in which case anyone can deposit it in their account. Or 
at least that's what the DigiCash people told me.

I think it only works that way if you select email payment, when it gives 
you a box for the account id to pay to.

	Mark

From tcmay at got.net  Tue Oct 31 10:39:08 1995
From: tcmay at got.net (Timothy C. May)
Date: Wed, 1 Nov 1995 02:39:08 +0800
Subject: payee anonymity
Message-ID: 

At 3:35 PM 10/31/95, Hal wrote:
>Another way payees could be anonymous would be to immediately spend their
>received coins, and do so anonymously.  This works for the online ecash
>system.  They simply pass the coins on without first exchanging them at
>the bank.  There would have to be something they wanted to buy that they
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>could receive anonymously, though.
>

Such as other coins?

(Since I hate cryptic one-liners, I'll elaborate. There seem to be enough
"degrees of freedom" involved in exchange of digital coins such that payee
and payer anonymity is achievable. "Coin mixes" using "shell game" methods
seem adequate. One puts N coins in, gets back N coins, spot checks the
validity of some of the coins by redeeming them, and everyone is happy.
Fraud is contained to manageable proportions.)

--Tim May

Views here are not the views of my Internet Service Provider or Government.
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
tcmay at got.net  408-728-0152 | anonymous networks, digital pseudonyms, zero
Corralitos, CA              | knowledge, reputations, information markets,
Higher Power: 2^756839      | black markets, collapse of governments.
"National borders are just speed bumps on the information superhighway."

From mark at grondar.za  Tue Oct 31 10:48:07 1995
From: mark at grondar.za (Mark Murray)
Date: Wed, 1 Nov 1995 02:48:07 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510311715.TAA05821@grumble.grondar.za>

>    How about SetGID? We were going for 660 root.kmem.
> 
> Bad idea; anyone who can run PGP could then get instant access to kmem

Fooey. Of course. Scratch that plan.

> 	cd /tmp
> 	ln -s /dev/kmem foo
> 	pgp -e tytso foo
> 	rm foo
> 	pgp foo.pgp

Eeeeek!

>    ? "Gut feel" suggests to me that large ammounts of "predicted" input might
>    be worse than the normal sort of system noise you have been using.
> 
> But keep in mind that what we're doing is XOR'ing the input data into
> the pool.  (Actually, it's a bit more complicated than that.  The input
> is XOR'ed in with a CRC-like function, generated by taking an
> irreducible polynomial in GF(2**128).  But for the purposes of this
> argument, you can think of it as XOR.)  So since you don't know what the
> input state of the pool is, you won't know what the output state of the
> pool.

I chatted with a colleague at work, and he helped bend my mind right.
I had the mistaken notion that adding lots of data would "overflow"
and "dilute" the entropy to an attackable state.

>    Is this millisecond accuracy quantifiable in terms of bits of entropy?
>    if so, the ethernet is surely safe?
> 
> Well, no.  If you're only using as your timing the 100Hz clock, the
> adversary will have a better timebase than you do.  So you may be adding
> zero or even no bits of entropy which can't be deduced by the adversary.

In a 386 or a 486 (under FreeBSD at least) there is a 1Mhz clock available.
How would _this_ be? On the Pentium there is the  register
which will give the board's oscillator (or 90 MHz) I believe.

> This is even worse in the PGP keyboard timing case, since the adversary
> almost certainly can find a better time resolution to measure your
> incoming packets when compared to the timing resolution that most
> programs have.  Far too many Unix systems only make a 100Hz clock
> available to the user mode, even if you have a better quality high
> resolution timing device in the kernel (for example, the Pentium cycle
> counting register).

Ah yes - _that_ register. :-)

What then is a body to do? Preserve all _verifiable_ randomness like gold?
Dish it out under some quota? A denial of service attack would be

forever {
	cat /dev/random > /dev/null
}

Severely limiting most decent folk's chance at getting PGP to work.

Right now I am considering making a piece of cheap hardware to deliver
noise to a digital input. (Electronics is a stagnant hobby of mine)
Interested? I may knock up a prototype in a month or so...

> The problem is that in order to do this requires making assumptions
> about what the capabilities of your adversary are.  Not only does this
> change over time, but certain adversaries (like the NSA) make it their
> business to conceal their capabilities, for precisely this reason.

Can they predict thermal noise in a cheap transistor? ]:->

> So I like to be conservative and use limits which are imposed by the
> laws of physics, as opposed to the current level of technology.  Hence,
> if the packet arrival time can be observed by an outsider, you are at
> real risk in using the network interrupts as a source of entropy.
> Perhaps it requires buidling a very complicated model of how your Unix
> scheduler works, and how much time it takes to process network packets,
> etc.  ---- but I have to assume that an adversary can very precisely
> model that, if they were to work hard enough at it.

This is a strong argument for some form of specialised noise source.
I have read of methods of getting this from turbulent air flow in a hard
drive (an RFC, I believe).

> People may disagree as to whether or not this is possible, but it's not
> prevented by the laws of physics; merely by how much effort someone
> might need to put in to be able to model a particular operating system's
> networking code.  In any case, that's why I don't like depending on
> network interrupts.  Your paranoia level may vary.

If I was running Fort Knox, I'd probably use Radioactive decay...

(From my experience working at a cyclotron facility - these SOB's are
_*RANDOM*_)

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From Mike_Spreitzer.PARC at xerox.com  Tue Oct 31 10:56:13 1995
From: Mike_Spreitzer.PARC at xerox.com (Mike_Spreitzer.PARC at xerox.com)
Date: Wed, 1 Nov 1995 02:56:13 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <9510310316.AA26268@dcl.MIT.EDU>
Message-ID: <95Oct31.094528pst."14855(1)"@alpha.xerox.com>

Blocking vs. non-blocking is a standard issue in design of U*X devices.
Standard solution: make it block by default, and accept an IOCTL to put it in
non-blocking mode.  There's even a POSIX way to do this:

	flags_or_err = fcntl(fd, F_GETFL, 0);
	{check for error}
	res = fcntl(fd, F_SETFL, flags_or_err | O_NONBLOCK);
	{check for error}

From tfs at vampire.science.gmu.edu  Tue Oct 31 11:21:41 1995
From: tfs at vampire.science.gmu.edu (Tim Scanlon)
Date: Wed, 1 Nov 1995 03:21:41 +0800
Subject: Four Horsemen (was Re: PA Remailer Concerns)
In-Reply-To: <3541.9510161053@exe.dcs.exeter.ac.uk>
Message-ID: <9510311715.AA01975@vampire.science.gmu.edu>

Sorry I'm late to the gate on this one, but from what
I have read on the traffic concerning this law (I've been
out of town a good bit lately, so I am playing catch-up)
there's been a few aspects of this odious law that have
been overlooked.

What struck me in a most glaring manner are the constitutional
issues surrounding this law. Specificly, aside from the remailer
aspects of the law, they attempt to enact prior restraint on
the publication of plans for electronic devices & the like.

The aspects of the law that cover publication do not look
as if they can pass constitutional muster. Especaily considering
the supreme court here has recently ruled that it is permissible
to publish unsigned political handbills and the like. Much like
what the output of an anonymous remailer produces after all.

Some of the issues they attempt to address in this law, are
done so poorly, and with such ignorance of legal precedent and
basic constitutional reference that I find it utterly amazing
that the govenor would sign it, and that it would have been
forwarded to him in the form they enacted.

I do not think that the law is capable of surviving any sort of
legal test based on much of what they've inserted. But I guess
that's for the courts to decide.

In any case, considering it's halloween, I would count the
Pensilvania Govenor lucky if Ben Franklin doesn't rise
from his grave and come strangle the bastard in his bed.

As it is, I'm sure old Ben could probably be used as a good
gyroscope with all the spinning in his grave that must be
going on. Pennsilvania the cradle of liberty? Hah, it looks
more like the cradle of repression to me. They sold liberty
and their souls in a devils bargain for an illusory peace of
mind with this one.

Tim Scanlon

________________________________________________________________
tfs at vampire.science.gmu.edu (NeXTmail, MIME)  Tim Scanlon
George Mason University     (PGP key avail.)  Public Affairs
I speak for myself, but often claim demonic possession

From hfinney at shell.portal.com  Tue Oct 31 11:33:11 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 1 Nov 1995 03:33:11 +0800
Subject: ecash remailer
In-Reply-To: <199510311625.IAA07105@infinity.c2.org>
Message-ID: <199510311703.JAA14785@jobe.shell.portal.com>

sameer  writes:

>To provide payee anonymity:

>Enterprising cypherpunk, Ed sets up the Ecash Remailer.

>Alice pays Bob e$15. Alice is anonymous.
>Bob sends Ed the e$15
>Ed cashes the e$ into his ecash mint account, withdraws e$13.50
>then pays Bob those e$14 .. Bob can now spend those e$ at will.

>	Bob is now anonymous.

>	This requires some trust-in-Ed, but Bob could be anonymous
>from Ed just as Ed is anonymous.

>	Perhaps this is the scheme lucky mentioned. I will have to get
>an account and implement it.

I think this is basically the scheme Lucky mentioned.  A more elaborate
version would have Bob sending Ed blinded proto-coins to be used in the
withdrawal.  However this would require hacking the ecash protocols to
work differently than intended, which would probably infringe the
patents.

What about this, though: Alice did not mean to pay Bob, but rather
Charlie, and Bob stole the coins.  He launders them through Ed's
service.  Charlie never got the cash, and Alice complains to the bank
that the coins were stolen.  The bank says, fine, we can identify the
perpetrator, let's see... it's Ed.  Ed is now charged with theft and
has an expensive and uncertain legal experience ahead of him.

Are you sure you want to put yourself in this position?  You might win,
but it could still be expensive (ask PRZ).  And if your service is seen
as a fencing operation to receive stolen goods with the legitimate uses
just a "cover", you could lose.

Also, I believe in normal use Digicash coins are marked as being for a
specific recipient.  This is not certain since no details have been
released.  And apparently it can be worked-around by the spender by
marking the recipient as just "@" (or some such string).  If this feature
is present in the Mark Twain cash then the payee-anonymity service may
not be very effective.

Hal

From nobody at c2.org  Tue Oct 31 11:33:40 1995
From: nobody at c2.org (nobody at c2.org)
Date: Wed, 1 Nov 1995 03:33:40 +0800
Subject: This PROMISes to be odius
Message-ID: <199510311823.KAA17396@infinity.c2.org>

>PR   10/18 0809  ORACLE INTRODUCES SOFTWARE TOOL FOR LAW ENFORCEMENT

Oracle should shange it's corporate motto to:
"Oracle, bringing Big Brother to life" or
something similar. The problem with this sort of
software is that it is virtually made to be abused.

It is very, very obvious that the profit motive and
the reassurances of LEO's have totaly blinded any 
shred of ethics the corporation might have once
entertained.

My reaction to this is simple. In the 70's, it was
acceptible reasoning for computer professionals to
not work in certain sectors of the industry because
they didn't want to be a part of the "military industrial
complex". 

The 90's version of that is simply not to buy products
from vendors who engage in unacceptible practices.
Oracle clearly falls in this latter catagory.

I had been looking very strongly at specifying a 
DB made by one of Oracles competition due to experience
with it's nightmarish installation procedures, but this
pretty much clinches the deal where nothing else would.

The funny thing here is that since this is just a current
sale, and since there's allready plenty of technical 
reasons to look at competing products, I'd bet even 
money that over a relativly short amount of time 
I can offset ALL of the sales for this odious LEO
product alone.

I would encourage others to do the same.

From jcastle at in-system.com  Tue Oct 31 11:37:13 1995
From: jcastle at in-system.com (Jim Castleberry)
Date: Wed, 1 Nov 1995 03:37:13 +0800
Subject: PGP 2.6.2 signator replacement bug fix
Message-ID: <9510311803.AA11158@toad.com>

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

Here's a fix for a minor bug in PGP 2.6.2.  I reported it to pgp-bugs last
February and they responded promptly, but it hasn't been propagated to the
release - I suppose 2.6.2 is "in the freezer".

Anyway, the bug can cause a crash and other folks might like to put in the
fix, so here it is.  Anyone have any others?

Jim Castleberry
jcastle at in-system.com

Original bug report starts here:
- -------------------------------------------------------------------------

I believe I've identified a bug in PGP 2.6.2.  The bug occurs on my system:
	HP 9000/735, running HPUX 9.03
	MIT PGP 2.6.2
	Compiled with either the native cc or gcc 2.6.3
	Optimization level doesn't change the behavior (from -O0 to +O3).
	pubring.pgp contains all the keys on the servers, plus a few
	   unpublished keys and some additional signatures.

When an existing signature is replaced by a newer one by the same signator,
memory gets corrupted.  On my system, this results in a program abort.

The problem is in file keyadd.c, function mergesigs().  When a signature is
(possibly) going to be replaced, user_from_keyID() is called to get a pointer
to the signator's user ID (as a C string in the in-memory user hash table.
Then that pointer is passed to check_key_sig(), which passes it to
getpublickey(), which passes it to readpublickey(), which reads successive
user ID strings into it while it searches for the desired keyID.  But the hash
table contains dynamically allocated strings that are only as long as the
string they hold.  So when a longer user ID is read into it, memory past the
end of the C string is corrupted.  That trashes a hash table entry ("struct
hashent"), destroying pointers and resulting in an illegal memory access later
in the program.

The offending code in mergesigs() only gets executed when a signature is being
replaced with a more recent one by the same signator.  It only showed up
because I updated my pubring with all new keys on the servers for the last 31
days, and one key has an updated sig on it:
   pub  1024/AB1F4831 1993/05/10 Robert Walking-Owl 
			         Robert Walking-Owl 

Here's a context diff for the fix.  The signator userid isn't needed by
check_key_sig() or the functions it calls since the signator's keyID is given,
and if the userid is NULL then readkeypacket() ignores it, so just pass NULL to
check_key_sig() and use the signator C string in mergesigs() as-is.

Jim Castleberry

- - cut here -------------------------------------------------------------------

*** old/keyadd.c	Wed Oct  5 20:48:11 1994
- --- keyadd.c	Wed Feb 15 22:37:53 1995
***************
*** 196,206 ****
  			    status = check_key_sig(fring,
  						   KeyIDpos, KeyIDlen,
  						   userid, fkey, keypos,
! 						   ringfile, signator,
  						   (byte *) & xstamp,
  						   &sigClass);
  			PascalToC(userid);
- - 			PascalToC(signator);
  			if (!status) {
  			    fprintf(pgpout,
  				    LANG("Replacing signature from %s\n"),
- --- 196,205 ----
  			    status = check_key_sig(fring,
  						   KeyIDpos, KeyIDlen,
  						   userid, fkey, keypos,
! 						   ringfile, NULL,
  						   (byte *) & xstamp,
  						   &sigClass);
  			PascalToC(userid);
  			if (!status) {
  			    fprintf(pgpout,
  				    LANG("Replacing signature from %s\n"),

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

iQEVAwUBMJZkDJYkAuN55UFhAQG8aQf/bsx7xlS9P9SBE8ysMEbjMkKwdf6yZSCt
fd0xBsUbTIsIS2Gzlx0ux7N3HWqJm/og2EBqebhfEzQk9IUBK8sp8Kbv8GtbUWrj
ai2b6/hxu2yXbtQEAmTDJLO3fQCZ6yjkydFYaz2n+HuRxN4h6TlWwIHzQWOBCxuK
qzPENr+c4YgMCHMVLGnAHDgPA8G9J/xX3UIPKQJQnrpAJwlGf+LTOkWeA+/kMLiw
aos108n6698mcsIxXzHltCVlCaYYY6meFMHzD4rGjXOCURTtKTSRx1dJ7WNSn+1N
JNwJSnFXrsvJRodko0fjpYnCUDNEbmEQgDsJX80wTdDfI+JH2LM/+g==
=jh+s
-----END PGP SIGNATURE-----

From hallam at w3.org  Tue Oct 31 12:16:56 1995
From: hallam at w3.org (hallam at w3.org)
Date: Wed, 1 Nov 1995 04:16:56 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <199510311650.IAA09144@ix2.ix.netcom.com>
Message-ID: <9510311855.AA00379@zorch.w3.org>

>I would prefer to see MD5 deleted.  A 128 bit hash simply seems too
>marginal in length for long term use in most hash applications.  I
>would much rather see something like Haval as a second hash algorithm.
>It can be faster than MD5, and can easily be tailored to the hash
>width you want.  If 128 bit hashes are really needed, use Haval's
>128-bit option.

MD5 is pretty well entrenched in IETF circles and since RSAREF only
provides Md2, MD4 and MD5 there has to be an option to use at least 
one of them. MD5 is the best of that set IMHO.

For Phil Rogaway's comments on keyed MD5 see :-

http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.tx
t

Unfortch much of the information he gave in his talk appears not to be there. 
C'est la vie as they say in Canada.

Also the cryptobytes article Miclael found an online for is well worth 
a look. http://www.rsa.com/rsalabs/cryptobytes/spring95/md5.htm
I would have quoted it but I didn't know it was avaliable in e-form. The
cryptobytes articles are well worth reading in general.

Also on Phil's page:
http://wwwcsif.cs.ucdavis.edu/~rogaway/papers/list.html

 Mihir Bellare, Roch Guerin and Phillip Rogaway
     XOR MACs: New methods for message authentication using finite pseudorandom 
functions,
     Crypto '95. 

	Phill

From karlmarx at illumini.demon.co.uk  Tue Oct 31 12:38:50 1995
From: karlmarx at illumini.demon.co.uk (Karl Marx)
Date: Wed, 1 Nov 1995 04:38:50 +0800
Subject: Nautullus Voice Encryption
Message-ID: <9510311908.aa17855@relay-3.mail.demon.net>

Hi!

I don't know if any of you have heard of the voice encryption program 
called Nautullus, but the full version was supposedly released 
sometime ago. Can someone please point me to a site where it is 
available ?

Thanks....

From perry at piermont.com  Tue Oct 31 12:42:06 1995
From: perry at piermont.com (Perry E. Metzger)
Date: Wed, 1 Nov 1995 04:42:06 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510302351.AA28243@zorch.w3.org>
Message-ID: <199510312331.SAA03949@jekyll.piermont.com>

hallam at w3.org writes:
> 	Do not spec Keyed MD5, it is a complete looser. It is actually weak
> against a number of attacks. There are much better constructs for creating
> a keyed digest. There are much better ways of creating a digest than using
> a hash fuinction as the base.

What??? 

A keyed version of MD5 is the base authentication mechanism in IPSP
and it has been heavily examined by a number of very good
cryptographers.

Perry

From Mike_Spreitzer.PARC at xerox.com  Tue Oct 31 12:59:25 1995
From: Mike_Spreitzer.PARC at xerox.com (Mike_Spreitzer.PARC at xerox.com)
Date: Wed, 1 Nov 1995 04:59:25 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510310427.AA28252@zorch.w3.org>
Message-ID: <95Oct31.115132pst."14646(5)"@alpha.xerox.com>

Isn't this what the GSS-API is about?  Couldn't HTTP-NG just convey GSS
"tokens", and do something about getting both sides to agree on which GSS
"mechanism" is to be used, and on what Principals are involved?

From rsalz at osf.org  Tue Oct 31 13:22:00 1995
From: rsalz at osf.org (Rich Salz)
Date: Wed, 1 Nov 1995 05:22:00 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
Message-ID: <9510312013.AA12543@sulphur.osf.org>

> Isn't this what the GSS-API is about?  Couldn't HTTP-NG just convey GSS
> "tokens", and do something about getting both sides to agree on which GSS
> "mechanism" is to be used, and on what Principals are involved?

Yes, exactly.  Of course negotiation and naming are often the harder
issues.  It is a pity that HTTP-NG seems to be inventing protocol-specific
crypto-systems, rather then designing a general one and then being its
first customer.
	/r$

From futplex at pseudonym.com  Tue Oct 31 13:33:03 1995
From: futplex at pseudonym.com (Futplex)
Date: Wed, 1 Nov 1995 05:33:03 +0800
Subject: ecash remailer
In-Reply-To: <199510311703.JAA14785@jobe.shell.portal.com>
Message-ID: <199510311940.OAA31415@opine.cs.umass.edu>

Hal writes:
[suggesting a problem with Ed the Currency Cleaner]
> What about this, though: Alice did not mean to pay Bob, but rather
> Charlie, and Bob stole the coins.  He launders them through Ed's
> service.  Charlie never got the cash, and Alice complains to the bank
> that the coins were stolen.  The bank says, fine, we can identify the
> perpetrator, let's see... it's Ed.  Ed is now charged with theft and
> has an expensive and uncertain legal experience ahead of him.

Jumping in hastily:

It seems to me that Ed faces a larger problem if the above scenario turns
out to be a viable attack. Consider the following sequence: Alice and
Charlie decide to get some (payee-anonymous) currency laundromat in hot 
water. Alice (payer-anonymously) washes some coins at the laundromat.
Con-man Charlie claims he didn't get paid for some fictional transaction with
Alice. Alice complains to the bank, and the rest proceeds as before. The
Alice-frames-Ed situation is functionally equivalent to the Bob-robs-Charlie
situation from the bank's perspective.

-Futplex 

From jsw at netscape.com  Tue Oct 31 13:36:11 1995
From: jsw at netscape.com (Jsw@netscape.com)
Date: Wed, 1 Nov 1995 05:36:11 +0800
Subject: CJR RETURNED TO SENDER
Message-ID: <9510310631062323@ci.diamond-bar.ca.us>

From: Jeff Weinstein 
Subject: Re: CJR returned to sender
Date: Mon, 30 Oct 1995 22:16:18 -0800
Organization: Netscape Communications Corporation

Timothy C. May wrote:
> 
> At 4:43 PM 10/26/95, Jeff Weinstein wrote:
> 
> >  The ITARs are currently keeping us(Netscape) from distributing
> >our US-only products to people within the United States.  We have
> >asked for clarification from the government about network distribution,
> >such as how much verification of location and citizenship of the
> >recipient we must do, and have yet to receive a response.  That
> >makes it more than just an export issue, at least for us.
> 
> And I agree that this is a much more important issue than whether a t-shirt
> can get an OK for export or not.
> 
> If the CJR for the t-shirt is ultimately granted, what useful information
> will be derived, or what implications for Netscape's question will be
> discovered?
> 
> If the CJR for the t-shirt is ultimately denied, ditto?

  It will force the bureaucrats to make a decision, which will be
the subject to much public scrutiny.  Hopefully it will generate a
stir in the press and inform many more people of the problems of
the current system.

        --Jeff

-- 
Jeff Weinstein - Electronic Munitions Specialist
Netscape Communication Corporation
jsw at netscape.com - http://home.netscape.com/people/jsw
Any opinions expressed above are mine.

From hallam at w3.org  Tue Oct 31 13:45:06 1995
From: hallam at w3.org (hallam at w3.org)
Date: Wed, 1 Nov 1995 05:45:06 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <199510312331.SAA03949@jekyll.piermont.com>
Message-ID: <9510312015.AA00768@zorch.w3.org>

>A keyed version of MD5 is the base authentication mechanism in IPSP
>and it has been heavily examined by a number of very good
>cryptographers.

Yes we reviewed it and said that it sucked.

Phil wrote a note to Ron and Ron sent in a series of comments. I suggested that
the idea of a keyed digest be stated as a separate concept from a hash function.
Functions of one variable are intrinsically different from functions of two 
variables.

The sequence of events I heard was that they asked Burt Kaliski for a suggestion,
he gave them one and they chose something different.

>Isn't this what the GSS-API is about?  Couldn't HTTP-NG just convey GSS
>"tokens", and do something about getting both sides to agree on which GSS
>"mechanism" is to be used, and on what Principals are involved?

GSS is often brought up on occasions like this. I have never seen an architectural
overview of what it is trying to achieve for me or how. When I am provided 
with a clear definition of what it is I hope to arrive at a clear explanation 
of why I'm not using it. Unfortunately the RFC process strips the rationale
part out of the specs. 

		Phill

From tytso at MIT.EDU  Tue Oct 31 13:48:18 1995
From: tytso at MIT.EDU (Theodore Ts'o)
Date: Wed, 1 Nov 1995 05:48:18 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510311715.TAA05821@grumble.grondar.za>
Message-ID: <9510312008.AA27100@dcl.MIT.EDU>

   Date: Tue, 31 Oct 1995 19:15:35 +0200
   From: Mark Murray 

   >    Is this millisecond accuracy quantifiable in terms of bits of entropy?
   >    if so, the ethernet is surely safe?
   > 
   > Well, no.  If you're only using as your timing the 100Hz clock, the
   > adversary will have a better timebase than you do.  So you may be adding
   > zero or even no bits of entropy which can't be deduced by the adversary.

   In a 386 or a 486 (under FreeBSD at least) there is a 1Mhz clock available.
   How would _this_ be? On the Pentium there is the  register
   which will give the board's oscillator (or 90 MHz) I believe.

What's HZ set at for FreeBSD?  Most of the x86 Unixes have generally
used HZ set at 100, because the interrupt overhead on a x86 isn't cheap,
and so you want to limit the number of clock interrupts.

You can sample the timing clock, but it turns out to be rather expensive
to do so; several I/O instructions, which will require several delays if
they have to go through your 8 MHz ISA bus.  We've moved away from using
the hardware clock on the 386 because of the overhead concerns.  On the
Penitum, we use the clock cycle counter.

   What then is a body to do? Preserve all _verifiable_ randomness like gold?
   Dish it out under some quota? A denial of service attack would be

Well, verifiable randomness really is like gold.  It's a valuable
resource.  On a time-sharing system, where you really want to equitably
share *all* system resources perhaps there should be a quota system
limiting the rate from which a user is allowed to "consume" randomness.

On the other hand, most Unix systems *aren't* great at doing this sort
of resource allocation, and there are enough other ways of launching
denial of service attacks.  "while (1) fork();" will generally bring
most systems to their knees, even in spite of limitations of the number
of processes per user.  Most Unix systems don't protect against one user
grabbing all available virtual memory.  And so on....

   forever {
	   cat /dev/random > /dev/null
   }

   Severely limiting most decent folk's chance at getting PGP to work.

If you have such a "bad user" on your system, and the PGP /dev/random
code is written correctly, it will only be a denial of service attack.
But it'll be possible to identify who the bad user is on your system,
and that person can then be dealt with, just as you would deal with some
user that used up all of the virtual memory on the system trying to
invert a 24x24 matrix, or some such ---- in both scenarios, the ability
for another user to run PGP is severely limited.  

There's nothing special about /dev/random in this sense; it's just
another system resource which can be abused by a malicious user, just
like virtual memory or process table slots.

   > So I like to be conservative and use limits which are imposed by the
   > laws of physics, as opposed to the current level of technology.  Hence,
   > if the packet arrival time can be observed by an outsider, you are at
   > real risk in using the network interrupts as a source of entropy.
   > Perhaps it requires buidling a very complicated model of how your Unix
   > scheduler works, and how much time it takes to process network packets,
   > etc.  ---- but I have to assume that an adversary can very precisely
   > model that, if they were to work hard enough at it.

   This is a strong argument for some form of specialised noise source.
   I have read of methods of getting this from turbulent air flow in a hard
   drive (an RFC, I believe).

Yes, ultimately what you need is a good hardware number generator.
There are many good choices; from radioactive decay, noise diodes, etc.

I'm not entirely comfortable with the proposal of using air flow
turbulance from a hard drive, myself, because the person who suggested
this still hasn't come up with a decent physical model which tells us
how many bits of true entropy this system really provides.  What Don
Davis did was to develop more and more sophisticated models, and
demonstrated that his more sophistcated models weren't able to explain
the "randomness" that he observed in the time that it took to complete
certain disk requests.  However, that doesn't prove that the
"randomness" is really there; it's just that he couldn't explain it
away.  It might be that the NSA has a much better model than Don Davis
was able to come up with, for example, and the amount of randomness from
air turbulance really is a lot less than one might expect at first
glance.

Short of good hardware sources, the other really good choice is
unobservable inputs.  Hence, the Linux driver is hooked into the
keyboard driver, and the various busmice drivers.  Those are really
wonderful sources of randomness, since they're generally not observable
by an adversary, and humans tend to be inherently random.  :-)

						- Ted

From nobody at REPLAY.COM  Tue Oct 31 13:48:31 1995
From: nobody at REPLAY.COM (Anonymous)
Date: Wed, 1 Nov 1995 05:48:31 +0800
Subject: InfoWar
Message-ID: <199510311811.TAA18276@utopia.hacktic.nl>

The Wall Street Journal, October 31, 1995, p. B1.

It's Time You Became A Manager of Change, The Consultants Say
[Excerpts]

Rapid innovation and product introduction require a nimbleness
lacking in many corporate bureaucracies.

"There's an intrinsic need to improve your effectiveness at
managing change -- whatever form it takes," says David Nadler,
chairman of the New York-based Delta Consulting Group.

Change-management boosters are also telling managers to learn
about "knowledge management" as a means of achieving their new
goals.

Knowledge management attempts to make fuller use of internal
information networks. The consulting units of Arthur Andersen,
Ernst & Young and Price Waterhouse are peddling systems to
collect, store and distribute knowledge. Andersen designates
"knowledge managers" who monitor traffic through its Lotus
Notes e-mail software and store valuable information on a CD-
ROM. The disk contains 16,000 pages on everything from
performance measurements to employee motivation.

One problem with the system: "It's so difficult to tie
knowledge-management systems to bottom-line improvement," says
C. Jack Grayson Jr., whose American Productivity and Quality
Center co-sponsored a knowledge-management symposium with
Arthur Andersen. "That just feeds suspicions that it's just
another fad."

It's also difficult to get employees to contribute to the
information pool [fearful their jobs may vanish after overt
knowledge-transfer, hence, the appeal to managers for systems
that covertly siphon knowledge and record grounds for
dismissal].

------

WSJ, October 24, 1995, p. A24.

Privacy Laws Are Lax On New Technology, Federal Agency Says 

Washington -- Inconsistent privacy laws let companies sell
sensitive information about consumers who use new
communications technologies, the Clinton administration
warned.

In a report, the Commerce Department's National
Telecommunications and Information Administration called on
communications companies to tell customers if they plan to
sell information about what they watch or whom they call, and
to make it easy for customers to squelch the disclosure of
sensitive information.

Federal regulations allow people to ask their phone company to
keep information confidential, but the rule generally doesn't
apply to small phone companies or wireless phones, according
to the report. Laws that prevent video stores from disclosing
what movies customers watch don't apply to pay-per-view
services by satellite-television providers. And while a 1986
law prevents on-line computer services from snooping into
electronic mail, it doesn't prevent the services from selling
information about who e-mailed whom, and what the topic was,
the report noted.

The Commerce Department stopped short of calling for
legislation to close the gaps. But "if industry doesn't do it,
consumers will demand that the government do it," predicted
Larry Irving, assistant commerce secretary for communications
and information.

Industry representatives played down the privacy loopholes.
Ronald Plesser, a Washington attorney who represents online
services and direct marketing firms, said, "I know of no
example of anybody trafficking in e-mail descriptions." A
spokeswoman for Hughes Electronics Corp.'s DirecTV said, "We
do not release names of customers that ordered movies.

-----

From sunder at amanda.dorsai.org  Tue Oct 31 13:58:16 1995
From: sunder at amanda.dorsai.org (Ray Arachelian)
Date: Wed, 1 Nov 1995 05:58:16 +0800
Subject: FCPUNX:Macintosh [and perhaps other OS] Security Alert (fwd)
Message-ID: 

==========================================================================
 + ^ + |  Ray Arachelian | Amerika: The land of the Freeh. |   _ |>
  \|/  |sunder at dorsai.org| Where day by day, yet another   |   \ |
<--+-->|                 | Constitutional right vanishes.  |    \|
  /|\  |    Just Say     |                                 |    <|\
 + v + | "No" to the NSA!| Jail the censor, not the author!|    <| n
==========================================================================

---------- Forwarded message ----------
Date: Sat, 28 Oct 1995 11:12:00 -0400
From: Sal Denaro 
To: Ray Arachelian 
Subject: Re: FCPUNX:Macintosh [and perhaps other OS] Security Alert (fwd)

> ---------- Forwarded message ----------
> Date: Sun, 15 Oct 1995 01:05:06 -0400
> From: Lucky Green 
> To: cypherpunks at toad.com
> Subject: Macintosh [and perhaps other OS] Security Alert
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> A number of months ago, I discovered that various Macintosh "unused
> diskspace" wipe utilities (Norton, Burn) fail to wipe the unused
> slackspace at the end of the last block allocated to a file. This leaves
> NumberOfFiles*512Bytes/2 = several kB of recoverable data on your average
> drive.
> 

I can verify that this is a cross-platform bug. The Dos/win3.1 and
Win95 versions all have the same flaw. 

-- 
Salvatore Denaro		
sal at panix.com                    Spinning dreams with angel wings
Yes, I use PGP                     torn blue jeans/a foolish grin

From shields at tembel.org  Tue Oct 31 14:59:10 1995
From: shields at tembel.org (Michael Shields)
Date: Wed, 1 Nov 1995 06:59:10 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510311715.TAA05821@grumble.grondar.za>
Message-ID: <47661e$6li@yage.tembel.org>

In article <199510311715.TAA05821 at grumble.grondar.za>,
Mark Murray  wrote:
> forever {
> 	cat /dev/random > /dev/null
> }
> 
> Severely limiting most decent folk's chance at getting PGP to work.

Ideally, if two processes are trying to read /dev/random at the same time,
both would get data at half-speed.  Doesn't it work that way already?
-- 
Shields.

From ses at tipper.oit.unc.edu  Tue Oct 31 15:11:30 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Wed, 1 Nov 1995 07:11:30 +0800
Subject: Cryto article in SJ Mercenary
Message-ID: 

There's a full page equivalent article on encyption in today's San Jose
Mercury News (12E-11E). The article concentrates on public key
cryptography, and mixes some good stuff with some silly mistakes. The
first page has about 4/5th of the article devoted to a big diagram showing
how someone using public key encryption to cover a whole message, and sent
it over the internet to someone in Argentina. All this without a mention
of using symmetric cyphers, and without even mentioning ITAR. 

Another 1/8th of this page is given over to a bunch of cypher text that
supposedly encodes the address of "Mr Cosmic Kumquat, SSl Trusters etc.." 
This address looks kind of familiar... but they seem to imply that the 
cyphertext is the output of an RSA encrpytion, not RC4. 

They then go on to discuss factoring, and explain the difference between 
the strength of algorithms in theory, and how Netscape became vulnerable 
due to "beginners mistakes" in the implementation, and how security is 
best assured by open disclosure, not security through obscurity. 

Simon
----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From mark at grondar.za  Tue Oct 31 15:12:33 1995
From: mark at grondar.za (Mark Murray)
Date: Wed, 1 Nov 1995 07:12:33 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199510312115.XAA06361@grumble.grondar.za>

>  In a 386 or a 486 (under FreeBSD at least) there is a 1Mhz clock available.
>  How would _this_ be? On the Pentium there is the  register
>  which will give the board's oscillator (or 90 MHz) I believe.
> 
> What's HZ set at for FreeBSD?  Most of the x86 Unixes have generally
> used HZ set at 100, because the interrupt overhead on a x86 isn't cheap,
> and so you want to limit the number of clock interrupts.

There are two interrupts 100Hz and the other 128Hz (The second gets pushed
into the +-1K region during profiling.

> You can sample the timing clock, but it turns out to be rather expensive
> to do so; several I/O instructions, which will require several delays if
> they have to go through your 8 MHz ISA bus.  We've moved away from using
> the hardware clock on the 386 because of the overhead concerns.  On the
> Penitum, we use the clock cycle counter.

Drat. Methinks I need to follow suit, but I value that 1Mhz...

> Well, verifiable randomness really is like gold.  It's a valuable
> resource.  On a time-sharing system, where you really want to equitably
> share *all* system resources perhaps there should be a quota system
> limiting the rate from which a user is allowed to "consume" randomness.

True. VMS could probably do this. 

> On the other hand, most Unix systems *aren't* great at doing this sort
> of resource allocation, and there are enough other ways of launching
> denial of service attacks.  "while (1) fork();" will generally bring
> most systems to their knees, even in spite of limitations of the number
> of processes per user.  Most Unix systems don't protect against one user
> grabbing all available virtual memory.  And so on....

Getting there (I think).

> There's nothing special about /dev/random in this sense; it's just
> another system resource which can be abused by a malicious user, just
> like virtual memory or process table slots.

True. Good policing never hurt.

>    This is a strong argument for some form of specialised noise source.
>    I have read of methods of getting this from turbulent air flow in a hard
>    drive (an RFC, I believe).
> 
> Yes, ultimately what you need is a good hardware number generator.
> There are many good choices; from radioactive decay, noise diodes, etc.

The idea that I like the most so far is to generate noise, but filter
it through an LPF to get frequencies less than (say) 500Khz. Put that
through schmitt trigger to get decent squarewaves and then into an
N-bit hardware shift register with some XOR feedbacks to mix this.
Voila! Nice numbers on demand. Shouldn't cost more than a few ...

> Short of good hardware sources, the other really good choice is
> unobservable inputs.  Hence, the Linux driver is hooked into the
> keyboard driver, and the various busmice drivers.  Those are really
> wonderful sources of randomness, since they're generally not observable
> by an adversary, and humans tend to be inherently random.  :-)

Doesn't work on servers in locked rooms... :-(
With those, as long as the machines are secure, (ie plebs cannot watch
and time raw packets) the network card is OK. The server may not be on
transit ethernet AT ALL.

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From lull at acm.org  Tue Oct 31 15:13:35 1995
From: lull at acm.org (John Lull)
Date: Wed, 1 Nov 1995 07:13:35 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510311855.AA00379@zorch.w3.org>
Message-ID: <199510312230.OAA15622@ix4.ix.netcom.com>

On Tue, 31 Oct 1995 13:55:34 -0500, you wrote:

> MD5 is pretty well entrenched in IETF circles

Agreed, but that doesn't make it appropriate here.

> and since RSAREF only
> provides Md2, MD4 and MD5 there has to be an option to use at least 
> one of them.

Why?  Is there some REAL requirement that HTTP-NG be implementable
using only RSAREF for crypto?

> MD5 is the best of that set IMHO.

No argument -- but it's still too short for most hash applications.
I'd much rather see hashes that everyone agrees are more than long
enough for the forseeable future  -- and I don't think you'll find
that consensus for MD5.

Of course, whether a particular hash is as secure as it can be for a
given length is a separate question.

Thanks for the pointers. 

From lep at tanju.wsnet.com  Tue Oct 31 15:22:42 1995
From: lep at tanju.wsnet.com (Alan Patterson)
Date: Wed, 1 Nov 1995 07:22:42 +0800
Subject: Need Mail-to-News gates
In-Reply-To: 
Message-ID: 

On Fri, 27 Oct 1995, Alan Patterson wrote:

> > Could someone PLEASE netmail me some _known reliable_ gates that use the
> > straight netmail address format (alt.whatnot at bosco.kollege.edu)?
> 
> If someone will direct me to sources, I'll try and setup a gate. (We use 
> INN).

I've gotten the gate up, but still working a few bugs out. Cypherpunks 
are welcome to use it but if it is abused, I will have to remove general 
access.

Until I can write a script to pull all the newsgroups from the active 
file and place aliases for them in sendmail, the only way to use it is 
via a Newsgroups: header. The address is mail2news at news.wsnet.com.

Let me know any bugs you may find.

Alan Patterson (lep at wsnet.com)        Fngpt: 41D0F61B496FECC09FABECF686AB2A1C
WSNetwork Communications Services, Inc.         PGP Encrypted Email Preferred
Montgomery, Alabama (334) 263-5505 (800) INET-750  Public Key @ MIT keyserver

From rah at shipwright.com  Tue Oct 31 15:23:41 1995
From: rah at shipwright.com (Robert Hettinga)
Date: Wed, 1 Nov 1995 07:23:41 +0800
Subject: A final Huber-Spam: ON MONEY
Message-ID: 

Note the URL.

There's more there for them as wants 'em.

Cheers,
Bob Hettinga

--- begin forwarded text

Date: Tue, 31 Oct 95 21:32:44 0500
From: Robert Hettinga 
Organization: Shipwright
MIME-Version: 1.0
To: rah at shipwright.com
Subject: 031692.html
X-URL: http://khht.com/huber/forbes/031692.html

http://khht.com/huber/forbes/031692.html>
 ON MONEY
>
> by Peter Huber
>
> Forbes, March 16, 1992 at Pg. 144
>
> Copyright 1992 by Peter Huber. Electronic copies of this document
> may be distributed freely, provided that this notice accompanies all
> copies.
>
> -------
>
> While Europe strains to give birth to a new currency, Boris Yeltsin
> toils to resurrect a dead one. With private markets triumphant
> everywhere else, however, the mystery is why governments still have
> to manufacture money at all.
>
> It is still often taken for granted that the one thing private
> markets cannot make is money itself: Only government can do that.
> But new governments of young nations, especially nations with
> turbulent histories, can't make money, either. Nobody quite trusts
> them, and without trust the paper lovingly engraved at the
> government mint is valueless.
>
> Until recently, people put up with a lot of government paper because
> even bad paper was more convenient than the alternative, which was
> barter. Every self-respecting capitalist knew that government paper
> was a perishable good, that it always decayed, slowly in
> Switzerland, fast in Brazil, and most just put up with it. But if
> capitalists can produce candies that melt in your mouth, not in your
> hand, why not currencies, too?
>
> Money, as I wrote here two years ago (FORBES, May 14, 1990), is just
> another network, our oldest medium of systematic communication. And
> new communications technologies are fast surpassing the old. The
> paperless bank, unlike the paperless office, is at hand.
>
> When it works, the old-fashioned paper we call money reliably
> records past effort and promises future return. It's all a matter of
> communication among stable communities of productive people. This is
> why individuals can issue currencies, too -- personal checks, IOUs,
> that sort of thing. Once it's established of an individual that her
> word is her bond, she can in fact issue private currency at will, at
> least among people who know her.
>
> But the trouble with private currencies has always been their
> informational overhead. Personal checks bounce, the "I" behind the
> IOU absconds to Monaco, Macy's defaults on its bonds. Private paper
> is also volatile; pegging current value requires specialized
> information from Wall Street, or a bank in Oshkosh, or a trading pit
> in Chicago. In the past, it's often been cheaper to put up with the
> steady but modest thievery of a central bank, which peels off 3%
> (will it soon be 6%?) of your dollar every year through inflation,
> than to sort out whose private paper is worth what at any given
> moment.
>
> Computers and fiber-optic communications are changing all that. Our
> new central bankers can be concerns like TRW and Dun & Bradstreet,
> which track who's solvent and who's a deadbeat and convey the
> information instantly, at the touch of a button, wherever it's
> needed. Our new mints and engravers can be companies like Visa and
> AT&T, which clear millions of transactions daily, both here and
> abroad.
>
> What enterprises like these supply are the informational ingredients
> of money. They already are far better than Alan Greenspan at
> stabilizing value by assembling baskets of private paper as varied
> and diversified as the global economy. Information about who earned
> a credit yesterday or who can be trusted to pay back a debt tomorrow
> can be passed around as easily as a dollar bill. More easily, in
> fact.
>
> Like religious liturgies conducted in some otherwise dead language,
> transactions may still be denoted in dollars or yen, but these
> vestiges of an earlier age will ultimately give way to a new
> financial vernacular. If everybody paid for everything (wages
> included) by credit card, for example, the accounts could just as
> well be denoted in pork bellies, IBM stock, quarterpounders with
> cheese, or (more likely) some very large basket of hundreds of
> different private goods and services, tangible and intangible.
>
> The Lynch, for example, might be a share in a standard pool of
> commodity receipts maintained by Merril Lynch. Nobody would fully
> trust the Lynch, of course, even if backed by 100% reserves, but
> nobody would have to. Nobody trusts his food supply to any one
> farmer, either. You diversify, you assemble baskets of baskets, and
> you constantly search for quality goods and reliable supply. Same
> with money. When the network and the computers behind it are
> powerful enough, no central authority can or should supply the
> currency, and no one will pay annual tribute by way of inflation to
> the government mint. And with private money, private fortunes will
> no longer be held hostage to public ineptitude in the Kremlin or on
> Capitol Hill.
>
> So back to Yeltsin and how we can help him. Despite the corrupting
> influences of the regulatory collectivist on our own shore,
> America's phone companies and banks are still the best in the world.
> Yeltsin needs them, far more than he needs the International
> Monetary Fund, Pizza Hut or Western investment in Russia's oil
> industry. Modern telefinancial enterprises can deliver the real oil
> of the economy: truly stable media of exchange.
>
> The biggest contribution Yeltsin can make to Russia's fiscal policy
> is to make way for currency capitalists. No exchange controls, no
> bank insurance, no loan guarantees, no criminal prosecution for
> ordinary bankruptcy, nothing but basic, narrowly interpreted laws
> against outright fraud.
>
> Will the new private banks sometimes fail? Of course they will. Will
> widows then be ruined? Certainly. So what else is new? In Russia
> today the only bank in town has failed miserably, and the one cold
> comfort for widows is that the ruin is universal. Give it a try,
> Boris. You have nothing to lose but your rubles.

--- end forwarded text

-----------------
Robert Hettinga (rah at shipwright.com)
Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131
USA (617) 323-7923
"Reality is not optional." --Thomas Sowell
>>>>Phree Phil: Email: zldf at clark.net  http://www.netresponse.com/zldf <<<<<

From sjb at universe.digex.net  Tue Oct 31 15:25:54 1995
From: sjb at universe.digex.net (Scott Brickner)
Date: Wed, 1 Nov 1995 07:25:54 +0800
Subject: InfoWar
In-Reply-To: <9510311924.AA09550@argosy.MasPar.COM>
Message-ID: <199510312244.RAA19266@universe.digex.net>

David G. Koontz writes:
> 
>>Industry representatives played down the privacy loopholes.
>>Ronald Plesser, a Washington attorney who represents online
>>services and direct marketing firms, said, "I know of no
>>example of anybody trafficking in e-mail descriptions." A
>>spokeswoman for Hughes Electronics Corp.'s DirecTV said, "We
>>do not release names of customers that ordered movies.
> 
>The name of the customer of a video tape rental may be disclosed
>only under narrow constraints (USC 18 Chap 121 2710):

Didn't you read the post?  The whole point was that the constraints
*don't* cover many *new* technology.  Sure, your local video store
can't release the data, but your *cable* company is under no such
constraint with regard to pay-per-view.  Ditto with Hughes DirecTV.

From sjb at universe.digex.net  Tue Oct 31 15:37:18 1995
From: sjb at universe.digex.net (Scott Brickner)
Date: Wed, 1 Nov 1995 07:37:18 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510311715.TAA05821@grumble.grondar.za>
Message-ID: <199510312247.RAA19315@universe.digex.net>

Mark Murray writes:
>Can they predict thermal noise in a cheap transistor? ]:->

As Perry pointed out in the last round on hardware noise generators, they
may not be able to predict it, but they *may* be able to generate a field
which will *influence* it.

It's difficult to know for sure if your noise source is really random,
and to what degree.

From mdiehl at dttus.com  Tue Oct 31 15:37:22 1995
From: mdiehl at dttus.com (Martin Diehl)
Date: Wed, 1 Nov 1995 07:37:22 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <9509318151.AA815185987@cc2.dttus.com>

     Theodore Ts'o writes...
     >Yes, ultimately what you need is a good hardware number generator.
     ...
     >I'm not entirely comfortable with the proposal of using air flow 
     >turbulance [sic] from a hard drive
     ...

     Two important observations about the use of a disk drive to get 
     randomness:

     1. In the case of some workstations, the local network provides the 
     disk drive and there isn't a local hard drive at all.  Hence, any 
     timing of disk accesses will give you data that is influenced by the 
     file server more than the disk drive.

     2. When doing time domain measurements (Hewlett Packard had some good 
     application notes on this subject), you must consider base clock 
     jitter.  Ill try to illustrate with a diagram:

     actual event:            V                    V
     clock granularity:  /...../...../...../...../...../...../

     the problem is that no matter how small the basic clock unit is 
     (symbolized by "/", above), you can't be sure how much of that unit 
     has passed when the event (symbolized by "V", above) occurs.  For 
     example, on the original IBM PC, clock interrupts occurred about 18.2 
     times per second (55ms interval).  In that architecture, you can't 
     time an event and have an uncertainty of less than 2 times 55ms

     If you propose using a special hardware random generator, you have a 
     different set of problems:

     1. You need to buy and install hardware on many different platforms -- 
     you don't always have access to do that.

     2. Many earlier posts on this subject pointed out that removing bias 
     was important.  In that case, you need to continuously test and 
     recertify the hardware random generator for randomness.  In order to 
     do that, you need to have so much knowledge about generating and 
     testing random numbers in software that you might as well use a 
     software solution in the first place.

     Good luck

From warlord at MIT.EDU  Tue Oct 31 15:47:59 1995
From: warlord at MIT.EDU (Derek Atkins)
Date: Wed, 1 Nov 1995 07:47:59 +0800
Subject: PGP 2.6.2 signator replacement bug fix
In-Reply-To: <9510311803.AA11158@toad.com>
Message-ID: <199510312113.QAA01220@toxicwaste.media.mit.edu>

PGP 2.6.2 is not going to be re-released.  I have been working on a
PGP 2.6.3 release, but I must admit that I haven't had as much time as
I would like to work on it.

Before 2.6.3 is released, all of the reported bugs (which are
currently archived and marked as fixed when the bug is fixed) will be
hand-checked.  Unfortunately I just have not had the time to work on
this, due to other obligations.  Hopefully I will have more time this
winter.

-derek

From ses at tipper.oit.unc.edu  Tue Oct 31 15:48:45 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Wed, 1 Nov 1995 07:48:45 +0800
Subject: PGP On shared machines (was Re: Keyed-MD5, ITAR, and HTTP-NG)
In-Reply-To: <3095c7353a43002@noc.cis.umn.edu>
Message-ID: 

One important thing to note in an academic environment is that if you 
have foreign students who are on non-green card visas, you may need to 
get an export licence if they can access the server. I expect you'll 
probably get the licence without too much hassle, and you're unlikely to 
be indicted for this, but it's something to be aware of.

Simon
----
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 
	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From ses at tipper.oit.unc.edu  Tue Oct 31 15:48:45 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Wed, 1 Nov 1995 07:48:45 +0800
Subject: Perfect Forward Secrecy - is it worth it?
Message-ID: 

Quick survey; how important is perfect forward secrecy to you? I've asked 
three people locally so far and gotten four different answers, so in the 
spirit of spreading divisiveness where'er I go, I'll try and get a few 
more opinions here :-) 

In general, schemes offering PFS require a extra PK-op, and an extra 
round-trip when compared to  non-PFS schemes. This cost is incurred once 
per "session", but can add on the order of seconds to startup times. 
Should key-management schemes where PK is available always provide PFS, 
allow PFS, or not provide PFS? The amount of code needed to implement 
each choice point is similar, if you're using something like BSAFE. 

Simon
---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1)  ((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From koontz at MasPar.COM  Tue Oct 31 15:49:33 1995
From: koontz at MasPar.COM (David G. Koontz)
Date: Wed, 1 Nov 1995 07:49:33 +0800
Subject: InfoWar
Message-ID: <9510311924.AA09550@argosy.MasPar.COM>

>Industry representatives played down the privacy loopholes.
>Ronald Plesser, a Washington attorney who represents online
>services and direct marketing firms, said, "I know of no
>example of anybody trafficking in e-mail descriptions." A
>spokeswoman for Hughes Electronics Corp.'s DirecTV said, "We
>do not release names of customers that ordered movies.

The name of the customer of a video tape rental may be disclosed
only under narrow constraints (USC 18 Chap 121 2710):

   *  (b) Video Tape Rental and Sale Records. - (1) A video tape service
     provider who knowingly discloses, to any person, personally identifiable
     information concerning any consumer of such provider shall be liable to
     the aggrieved person for the relief provided in subsection (d).

     (2) A video tape service provider may disclose personally identifiable
     information concerning any consumer -
        o  (A) to the consumer;
        o  (B) to any person with the informed, written consent of the consumer
          given at the time the disclosure is sought;
        o  (C) to a law enforcement agency pursuant to a warrant issued under
          the Federal Rules of Criminal Procedure, an equivalent State warrant,
          a grand jury subpoena, or a court order;
        o  (D) to any person if the disclosure is solely of the names and
          addresses of consumers and if -
             +  (i) the video tape service provider has provided the consumer
               with the opportunity, in a clear and conspicuous manner, to
               prohibit such disclosure; and
             +  (ii) the disclosure does not identify the title, description,
               or subject matter of any video tapes or other audio visual
               material; however, the subject matter of such materials may be
               disclosed if the disclosure is for the exclusive use of
               marketing goods and services directly to the consumer;
        o  (E) to any person if the disclosure is incident to the ordinary
          course of business of the video tape service provider; or
        o  (F) pursuant to a court order, in a civil proceeding upon a showing
          of compelling need for the information that cannot be accommodated by
          any other means, if -
             +  (i) the consumer is given reasonable notice, by the person
               seeking the disclosure, of the court proceeding relevant to the
               issuance of the court order; and
             +  (ii) the consumer is afforded the opportunity to appear and
               contest the claim of the person seeking the disclosure. If an
               order is granted pursuant to subparagraph (C) or (F), the court
               shall impose appropriate safeguards against unauthorized
               disclosure.

               (3) Court orders authorizing disclosure under subparagraph (C)
               shall issue only with prior notice to the consumer and only if
               the law enforcement agency shows that there is probable cause to
               believe that the records or other information sought are
               relevant to a legitimate law enforcement inquiry. In the case of
               a State government authority, such a court order shall not issue
               if prohibited by the law of such State. A court issuing an order
               pursuant to this section, on a motion made promptly by the video
               tape service provider, may quash or modify such order if the
               information or records requested are unreasonably voluminous in
               nature or if compliance with such order otherwise would cause an
               unreasonable burden on such provider.
   *  (c) Civil Action. - (1) Any person aggrieved by any act of a person in
     violation of this section may bring a civil action in a United States
     district court.

In other words it can be a federal crime to release personal info.
(Without regard to ordering movies over the internet)

From frezza at interramp.com  Tue Oct 31 15:49:56 1995
From: frezza at interramp.com (Bill Frezza)
Date: Wed, 1 Nov 1995 07:49:56 +0800
Subject: Electronic Warfare
Message-ID: 

Cypherpunks,

With your indulgence I would like to post this short essay here, which was
stimulated by a recent report posted on this list that was passed on to me.
The essay just ran as an op-ed piece in this week's issue of Communications
Week. I would like to thank and acknowledge the author off the original
report as well as encourage the cypherpunk community to keep me posted on
related issues. (I cannot keep up with the volume on this list and, hence,
am not a subscriber.)

Thank you,

Bill Frezza
Columnist
Communications Week
Network Computing Magazine
frezza at interramp.com

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

ELECTRONIC WARFARE WAGES ON - AND YOU'RE THE TARGET

Although the flap over the Clinton administration's attempt to promote
escrowed-key encryption systems like Clipper has temporarily faded, the war
on electronic privacy continues.   As proceedings at the Fourth
International Conference on Money Laundering, Forfeiture, Asset Recovery,
Offshore Investments, the Pacific Rim, and International Financial Crimes
reveal, there has been no let up in our government's efforts to blockade
the cyber-frontier.

No, you won't learn much from the Wall Street Journal or the New York
Times, written by journalist-generalists who have no clue about where this
technology is heading.  The Feds have become so skilled at manipulating the
Old Media that stories about electronic privacy  invariably center on the
latest drug kingpin, pedophile, or domestic terrorist.  Attacking these
universally abhorred enemies of the people not only makes for good
headlines but keeps privacy advocates off balance as they are forced to
defend abstract rights using loathsome examples.  But if you tune in to the
Cypherpunks mailing list (majordomo at toad.com) you can get some excellent
first hand reports from the front.

In the relatively short period since the passage of the Bank Secrecy Act,
which, among other things, obliges banks to file Suspicious Activity
Reports on its customers, banks have become virtual deputies in the
treasury department's war on uncontrolled financial transactions.  And this
war is increasingly spilling into cyberspace.

The conference underscored the fact that, paradoxically, we are heading not
toward more specific and well defined transaction monitoring regulations,
but less.  How so?  The problem with making regulations precise is that
what software algorithms can define, other algorithms can evade.  Instead,
regulation by "raised eyebrow" is becoming the norm.  Federal bank
examiners have been given significant latitude to invoke draconian
penalties against uncooperative banks.  Because bank officers have few
due-process protections under this regime, it is no surprise that most of
them have become sniveling toadies.  The objective is to insure that banks
"voluntarily" introduce even more aggressive, unpredictable, and intrusive
monitoring than the government would ever dare mandate.  And to make sure
nothing slips through the cracks, human surveillance will be supplemented
with artificial-intelligence agents that can perform pattern analysis on
the aggregate flow of electronic transactions, flagging anything remotely
suspicious.  George Orwell would be impressed.

Lest you think that all of this is motivated solely by the drug war,  a
visit to the Treasury Department's Financial Crimes Enforcement Network
(FinCEN) homepage
(http://www.ustreas.gov/treasury/bureaus/fincen/facts.html) should open
your eyes.  This battle is not just about drug prohibition, a crime the
Treasury Department would have to invent if it didn't already exist.  The
real struggle is about the future of tax compliance, and it has you in its
sights.

A famous Revolutionary War era pamphleteer, writing under the pseudonym
"Brutus", perhaps said it best 200 years ago when he wrote - "The national
government through its taxing power will introduce itself into every corner
of the city and country.  It will take cognizance of the professional man
in his office or his study;  it will watch the merchant in his store;  it
will follow the mechanic to his shop and his work, and will haunt him in
his family and his bed;  it will be the constant companion to the
industrious farmer in his labour;  it will penetrate into the most obscure
cottage;  and finally it will light upon the head of every person in the
United States.  To all these different classes of people and in all these
circumstances on which it will attend them, the language in which it will
address them will be GIVE! GIVE!"

What Brutus didn't know and what the cypherpunks foresee is that one day
strong encryption will make it impossible to spy on our activities in
cyberspace.  Heightened conflict is inevitable.  Expect the rhetoric to get
a lot hotter as the government spinmeisters labor to keep us focused on
public enemies while frantically trying to keep its hand in every citizens
pocket and its eyes on every bankbook.

# # #
COPYRIGHT CMP PUBLICATIONS 1995

Bill Frezza is president at Wireless Computing Associates and co-founder of
the online forum DigitaLiberty.  The opinions expresses are his own. Frezza
can be reached at frezza at interramp.com.

 ------------------------------------
| Wireless Computing Associates, Inc.
| 704 Stoney Hill Rd., Suite 155
| Yardley, PA 19067
| ph 215-321-0929, fax 215-321-0490
| urgent Email: frezza at radiomail.net
| bulk Email: frezza at interramp.com
 ------------------------------------

From sjb at universe.digex.net  Tue Oct 31 16:02:46 1995
From: sjb at universe.digex.net (Scott Brickner)
Date: Wed, 1 Nov 1995 08:02:46 +0800
Subject: CJR returned to sender
In-Reply-To: <199510280045.RAA10830@email.pdcorp.com>
Message-ID: <199510312113.QAA16575@universe.digex.net>

Dan Weinstein writes:
>>If anyone from MIT is reading this, it would be a real public service to 
>>put on a web site (a) what the system used for the release of PGP is 
>>exactly and (b) what assurances (oral, written, names & dates) was 
>>received from State/Commerce that this was legal.
>
>You are assuming that because the government has chosen not to
>prosecute MIT that they will not prosecute anyone else.  This is a
>faulty assumption, laws are not invalidated if they are not enforced,
>only if they are repealed or overturned.

IANAL, but this seems implausible.  If MIT has received assurances
(written or oral) from the DoJ that indicate that their scheme is
adequate, then another organization prosecuted while following an
identical scheme can admit this as evidence.

There isn't, to my knowledge, a specific law which defines the act of
export over the 'net.  The DoJ, in effect, determines the definition by
their actions.  Failure to prosecute MIT should lead a responsible
judge to dismiss actions against a subsequent defendant that follows
the same practice.

I agree that things would be different in cases like traffic laws:  the
fact that millions of people exceed legal speed limits every day
doesn't make speeding laws invalid, but this is a matter where there is
no question whether the act broke the law.  Where the line is drawn by
the legislature, failure of the executive does not invalidate the law
--- it merely tarnishes the reputation of the executive.  Where the
line is drawn by the executive, failure to prosecute moves the line,
IMHO.

From rsalz at osf.org  Tue Oct 31 16:24:14 1995
From: rsalz at osf.org (Rich Salz)
Date: Wed, 1 Nov 1995 08:24:14 +0800
Subject: Need Mail-to-News gates
Message-ID: <9510312340.AA12914@sulphur.osf.org>

>Until I can write a script to pull all the newsgroups from the active 
>file and place aliases for them in sendmail, the only way to use it is 

The "gag" program that comes with my news/mail gateway software known
as newsgate can do this automatically.  email to rsalz at nntp.com for
a copy.

From hallam at w3.org  Tue Oct 31 16:27:05 1995
From: hallam at w3.org (hallam at w3.org)
Date: Wed, 1 Nov 1995 08:27:05 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510310430.AA08480@sulphur.osf.org>
Message-ID: <9510311650.AA32634@zorch.w3.org>

>How are you going to handle mechanism negotiation?

This is a must do item, Simon is haviung to do >lots< of this.

One way of looking at HTTP is as a huge negotiation mechanism. Another way to
look at HTTP is as a large dougnut with sugar frosting, the first is more widely 
accepted.

There has to be more than one crypto mechanism so don't chose. In fact I forgot to 
add our favourite algorithms, such as Skipjack in OFB mode to the list :-)

What DES modes should be bothered with? I always feel that the lumping in of every 
cipher mode under the sun is an irritation. We need a transparent cipher, looking 
very much like a stream cipher (hence the probable reason for Simon hankering after 
RC4). We could use CFB or OFB. 

I don't like OFB myself, it seems to be a bit lame to only XOR a stream of pseudo 
random stuff with the plaintext. CFB also has the stream cipher like property that 
incomplete blocks can be decoded provided that the stride is set right, this means 
that for a 64 bit block cipher one is 8 time slower :-(

Anyone any ideas on the following ?

SEQ
    x = IV
    SEQ
    	c[i] = E(x,K) XOR p[i]
    	x = c[i] 

This is essentially OFB mode but instead of having an XOR with an alledged random 
number generator (which I find disturbing), there is a mix in of the output.

Other mixes to try ?

	x = c[i] XOR E(x,K)

OFB is the following BTW :-

	x = E(x,K)

Note that there may be value in keeping the IV secret in this case. There is probably 
some hack that means that the IV can be finessed but it looks like work.

		Phill

From fc at all.net  Tue Oct 31 16:31:24 1995
From: fc at all.net (Dr. Frederick B. Cohen)
Date: Wed, 1 Nov 1995 08:31:24 +0800
Subject: Please send cash
Message-ID: <9510312359.AA21087@all.net>

I just picked this up from the Risks forum:

> Date: Mon, 30 Oct 1995 16:14:59 -0500
> From: Drew Dean 
> Subject: HotJava 1.0 alpha 3 security issues
> 
> We have found several security problems in the 1.0 alpha 3 release of
> HotJava from Sun Microsystems.  The two most important problems are that
> HotJava does not enforce the stated limits on where an applet can connect to
> (an applet can talk to any place with which you have IP-level connectivity),
> and HotJava is vulnerable to a man-in-the-middle attack, where someone can
> watch your web-surfing, both seeing your requests, and the content that you
> receive.

Two of the Java attacks I outlined in this forum and got abuse for.

> While HotJava prevents applets from actively opening connections that
> violate the user-selected security policy, it allows an applet to accept
> connections from anywhere.  At this point, an applet only has to use any one
> of a number of channels to communicate where it is, and have the remote end
> do the active open.
> 
> HotJava also allows an applet to set the proxy servers that the browser
> uses.  This opens up a huge hole for anyone concerned about the privacy of
> their web surfing.

Attacks 31-49 work here.

> Please note that these bugs are specific to the 1.0 alpha 3 release, and are
> _not_ bugs in the Java language itself, nor do they apply to Netscape 2.0
> beta 1J, which doesn't permit network connections.  We have notified Sun of
> these problems, and are presently writing a paper on these and other issues.
> We will make more information available on our Web page after we hear back
> from Sun.

Drat - Sun doesn't offer awards.

> 
>     http://www.cs.princeton.edu/~ddean/java/
> 
> Drew Dean				Dan Wallach
> ddean at cs.princeton.edu			dwallach at cs.princeton.edu

Inquiring minds want to know.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

From rsalz at osf.org  Tue Oct 31 16:41:48 1995
From: rsalz at osf.org (Rich Salz)
Date: Wed, 1 Nov 1995 08:41:48 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
Message-ID: <9510312348.AA12963@sulphur.osf.org>

>GSS is often brought up on occasions like this. I have never seen an architectural
>overview of what it is trying to achieve for me or how. When I am provided 
>with a clear definition of what it is I hope to arrive at a clear explanation 
>of why I'm not using it. Unfortunately the RFC process strips the rationale
>part out of the specs. 

You don't understand it, but once you do you can explain why you're not
using it?  Do you really mean that, or am I misunderstanding?

Many of the GSSAPI principals are in the Boston area:  John Linn at
OpenVision in Cambridge, John Wray at Digital in Littleton, Ted T'so
and Marc Horowitz at MIT, etc.

If you would like to have a discussion, face-to-face or phone, let
me know and I will try to work something out.
	/r$

From tomw at orac.engr.sgi.com  Tue Oct 31 16:41:50 1995
From: tomw at orac.engr.sgi.com (Tom Weinstein)
Date: Wed, 1 Nov 1995 08:41:50 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: 
Message-ID: <199510311648.IAA05877@orac.engr.sgi.com>

In article , "Theodore Ts'o"  writes:

>    Date: Mon, 30 Oct 1995 21:59:14 -0500
>    From: "Josh M. Osborne" 

>    When /dev/random doesn't have "enough" enthropy left does reading
>    from it return an error, or block?  I would strongly suggest
>    blocking, as the non-blocking behavur is not really all that useful.

> It acts like many character devices and named pipes in that if there is
> no entropy available at all, it blocks.  If there is some entropy
> available, but not enough, it returns what is available.  (A subsequent
> read will then block, since no entropy will then be available.)

> Actually, what's currently in Linux doesn't work precisely like this,
> but it will soon.  After talking a number of people on both sides of the
> block vs. non-blocking camp, this seemed to be a suitable compromise.
> At least one Major Workstation Vendor is planning on using this behavior
> for their /dev/random, to appear in a future OS release.  If we all can
> standardize on this behavior, it'll make application writer's jobs that
> much easier.

One problem with this scheme is that if multiple processes have
/dev/random open you can block unexpectedly.  If I try to avoid blocking
by first checking if entropy is available there's a race condition if
another process reads from the device.  Is there another way to avoid
blocking?

-- 
Sure we spend a lot of money, but that doesn't mean | Tom Weinstein
we *do* anything.  --  Washington DC motto          | tomw at engr.sgi.com

From hfinney at shell.portal.com  Tue Oct 31 17:13:58 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 1 Nov 1995 09:13:58 +0800
Subject: CJR returned to sender
In-Reply-To: <199510312113.QAA16575@universe.digex.net>
Message-ID: <199511010030.QAA09462@jobe.shell.portal.com>

Scott Brickner  writes:
>Dan Weinstein writes:
[unknown writes:]
>>>If anyone from MIT is reading this, it would be a real public service to 
>>>put on a web site (a) what the system used for the release of PGP is 
>>>exactly and (b) what assurances (oral, written, names & dates) was 
>>>received from State/Commerce that this was legal.
>>
>>You are assuming that because the government has chosen not to
>>prosecute MIT that they will not prosecute anyone else.  This is a
>>faulty assumption, laws are not invalidated if they are not enforced,
>>only if they are repealed or overturned.

>IANAL, but this seems implausible.  If MIT has received assurances
>(written or oral) from the DoJ that indicate that their scheme is
>adequate, then another organization prosecuted while following an
>identical scheme can admit this as evidence.

>There isn't, to my knowledge, a specific law which defines the act of
>export over the 'net.  The DoJ, in effect, determines the definition by
>their actions.  Failure to prosecute MIT should lead a responsible
>judge to dismiss actions against a subsequent defendant that follows
>the same practice.

It is also worth noting that the ITAR violation is worded somewhat
differently from some laws, requiring "willful" violation, a "specific
intent" to break the law.  In this situation, good faith efforts to apply
with what the law appears to be would seem to me to be a strong defense.
See  for a writeup
I did on this a couple of years ago.  An excerpt, from U.S. v
Lizarraga-Lizarraga (541 F2d 826):

"Accordingly, we hold that in order for a defendant to be found guilty of
exporting under 22 U.S.C. 1934, the government must prove that the
defendant voluntarily and intentionally violated a known legal duty not
to export the proscribed articles, and the jury should be so instructed."

I am not a lawyer, however.  It would be interesting to hear what our
legal exports think of this argument.

Hal

From don at cs.byu.edu  Tue Oct 31 17:22:23 1995
From: don at cs.byu.edu (Don M. Kitchen)
Date: Wed, 1 Nov 1995 09:22:23 +0800
Subject: ecash remailer
In-Reply-To: <199510311940.OAA31415@opine.cs.umass.edu>
Message-ID: 

>  > perpetrator, let's see... it's Ed.  Ed is now charged with theft and
>  > has an expensive and uncertain legal experience ahead of him.
>  
>  Alice-frames-Ed situation is functionally equivalent to the Bob-robs-Charlie
>  situation from the bank's perspective.

I suppose the word "receipt" might be handy to introduce into the entire
scheme. A dispute over who payed & who stole is solved with paperwork of some
sort. Although a digital signature is not necessarily valid (I don't even know
what the Utah Digital Signature Law does) but the bank, as rule-setter
is allowed to say that a digital receipt DOES bind the parties in some
way.

Don

From ylo at cs.hut.fi  Tue Oct 31 17:43:02 1995
From: ylo at cs.hut.fi (Tatu Ylonen)
Date: Wed, 1 Nov 1995 09:43:02 +0800
Subject: Cryto article in SJ Mercenary
In-Reply-To: 
Message-ID: <199510312340.AAA05687@soikko.cs.hut.fi>

> There's a full page equivalent article on encyption in today's San Jose
> Mercury News (12E-11E). The article concentrates on public key
> cryptography, and mixes some good stuff with some silly mistakes. The
> first page has about 4/5th of the article devoted to a big diagram showing
> how someone using public key encryption to cover a whole message, and sent
> it over the internet to someone in Argentina. All this without a mention
> of using symmetric cyphers, and without even mentioning ITAR. 

I don't think ITAR is very relevant here.  After all, there are dozens
of RSA implementations available from outside the US, and they are not
patent-restricted like in the US.  It is really much easier to use and
get RSA *outside* the US than inside.  (For some pointers, see
"http://www.cs.hut.fi/crypto/".)  Besides, as far as I understand, one
of the RSA inventors wasn't even a US citizen...

    Tatu

From perry at piermont.com  Tue Oct 31 17:43:29 1995
From: perry at piermont.com (Perry E. Metzger)
Date: Wed, 1 Nov 1995 09:43:29 +0800
Subject: Keyed-MD5, and HTTP-NG
In-Reply-To: <9509308151.AA815103202@snail.rsa.com>
Message-ID: <199511010004.TAA14640@jekyll.piermont.com>

"baldwin" writes:
> Simon,
>         There are a few different ways to add key material to MD5 to
> make it suitable as a shared-secret authenticator function.  Some of these
> are less resistant to attacks than others.  For example, the keyed MD5
> mechanism that is part of the current IPsec specifications can be
> attacked using 2**60 chosen messages.  Fortunately, the IPsec specs
> also require that the shared MD5 key be changed every 2**32 messages,
> so this attack is unlikely to succeed.  Specifically, IPsec uses
> MD5 as follows:  X = MD5(key | keypad | Message), where "|" means
> concatenation and the "keypad" pads out the key to 512 bits.
> Basically, this function is the same as standard MD5 with a
> different initialization vector for the compression operation
> on the first block of the message.
>         RSA Labs recommends that a people use an authenticator like
> X = MD5(key1, MD5(key2, Message)).  This resists the chosen plaintext
> attacks that were published at the crypto conference in Spring 1995.

Pardon me. The amount of vitriol I am going to spew is probably
difficult for people to understand because most folks around here
weren't following the keyed MD5 discussions during the IPSEC work and
have no idea of the sort of crap the professional cryptographic
community put us through.

We spent months, and months, and months, and months, getting advice
from every cryptographer on the planet. Every conceivable combination
of pads, multiple keys, keys before the text, after, before and after,
etc., was discussed over and over and over again.

Finally, the folks at RSA and IBM both agreed that Hugo's scheme, the
one we were putting in to place, was the best possible one. (Thats the
one with the padded key.)

What the flying hell are you doing telling us now, and indeed not even
telling the IPSEC community but instead mumbling on cypherpunks, that
you guys were in possession of information BEFORE the entire
discussion in midsummer that indicated that your own advice was wrong?

Perry

From perry at piermont.com  Tue Oct 31 17:49:27 1995
From: perry at piermont.com (Perry E. Metzger)
Date: Wed, 1 Nov 1995 09:49:27 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199510311648.IAA05877@orac.engr.sgi.com>
Message-ID: <199511010026.TAA22659@jekyll.piermont.com>

Tom Weinstein writes:
> One problem with this scheme is that if multiple processes have
> /dev/random open you can block unexpectedly.  If I try to avoid blocking
> by first checking if entropy is available there's a race condition if
> another process reads from the device.  Is there another way to avoid
> blocking?

Yeah. Use non-blocking I/O. Its in every version of Unix I've touched
for over a decade.

.pm

From tomw at cthulhu.engr.sgi.com  Tue Oct 31 18:02:57 1995
From: tomw at cthulhu.engr.sgi.com (Tom Weinstein)
Date: Wed, 1 Nov 1995 10:02:57 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
In-Reply-To: <199511010026.TAA22659@jekyll.piermont.com>
Message-ID: <3096CA5A.41C6@engr.sgi.com>

Perry E. Metzger wrote:
> 
> Tom Weinstein writes:
> > One problem with this scheme is that if multiple processes have
> > /dev/random open you can block unexpectedly.  If I try to avoid
> > blocking by first checking if entropy is available there's a race
> > condition if another process reads from the device.  Is there
> > another way to avoid blocking?
> 
> Yeah. Use non-blocking I/O. Its in every version of Unix I've touched
> for over a decade.

I guess I wasn't clear.  The message I was replying to defined how
the driver decided whether to block.  Since I don't have the source
code, I was wondering whether non-blocking I/O worked for this driver.

-- 
Sure we spend a lot of money, but that doesn't mean | Tom Weinstein
we *do* anything.  --  Washington DC motto          | tomw at engr.sgi.com

From ses at tipper.oit.unc.edu  Tue Oct 31 18:03:15 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Wed, 1 Nov 1995 10:03:15 +0800
Subject: Keyed-MD5, ITAR, and HTTP-NG
In-Reply-To: <9510311650.AA32634@zorch.w3.org>
Message-ID: 

[Short response, because I'm at home. More details tommorow ]

On Tue, 31 Oct 1995 hallam at w3.org wrote:

> 
> >How are you going to handle mechanism negotiation?
> This is a must do item, Simon is haviung to do >lots< of this.

Just to clarify: one of the most important parts of the design is the 
negotation mechanism, so a lot of effort has gone into these mechanisms. 
The aim is to _not_ have to do lots of RTT negotations through the use of 
caching and dynamic profiling. The negotation facilities in HTTP 1.0 are not 
used, not because there isn't a need for them, but because they don't 
offer sufficient power, and are much too inefficient. 

Oh, and when I say dynamic profiling, I'm referring to semi-standard 
profiles that can be obtained over the network, not to OSI style 
dead-trees. Deriving negotiated feature sets from a profile works really 
well for applications like the WEB, as a vast amount of this information 
remains the same for all copies of a particular version of a Browser. For 
example, all copies of hotjava support html 1.0, some netscape 
extensions, and can handle inline gifs, but not inline jpegs; alpha 
hotjava supports the alpha applet API. 

Simon
---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1) 	((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From sunder at amanda.dorsai.org  Tue Oct 31 18:07:46 1995
From: sunder at amanda.dorsai.org (Ray Arachelian)
Date: Wed, 1 Nov 1995 10:07:46 +0800
Subject: From Bill Frezza: Electronic Warfare
Message-ID: 

---------- Forwarded message ----------
Date: Sun, 29 Oct 1995 11:33:54 -0500
From: Bill Frezza 
To: sunder at escape.com
Subject: Can you post this?

Ray,

If you feel it is apporpriate, can you post the attached column to
cypherpunks? Since I am not a regular subscriber (I can't keep up with the
traffic) I thought it would be best to pass it by you first.

Thanks,

Bill Frezza
------------------------------------------------------------------------------
To: Cypherpunks at toad.com
Subject: Electronic Warfare
From: Bill Frezza (frezza at interramp.com)

Dear cyhperpunks,

Attached is a column that will appear on the op-ed page of tomorrow's
(10/30) Communications Week that was stimulated largely by a report filed
here by one of your members. I thought you would find it interesting and
thought provoking. I would like to thank and acknowledge whoever it was
that filed that report as well as encourage you all to keep me informed
about related political developments. (I just don't have the bandwidth to
follow the cyhperpunks list in its entirty.)  It is my hope to bring the
important issues you raise here to the attention of the industry and the
general public.

Regards,

Bill Frezza
Communications Week

ELECTRONIC WARFARE WAGES ON - AND YOU'RE THE TARGET

Although the flap over the Clinton administration's attempt to promote
escrowed-key encryption systems like Clipper has temporarily faded, the war
on electronic privacy continues.   As proceedings at the Fourth
International Conference on Money Laundering, Forfeiture, Asset Recovery,
Offshore Investments, the Pacific Rim, and International Financial Crimes
reveal, there has been no let up in our government's efforts to blockade
the cyber-frontier.

No, you won't learn much from the Wall Street Journal or the New York
Times, written by journalist-generalists who have no clue about where this
technology is heading.  The Feds have become so skilled at manipulating the
Old Media that stories about electronic privacy  invariably center on the
latest drug kingpin, pedophile, or domestic terrorist.  Attacking these
universally abhorred enemies of the people not only makes for good
headlines but keeps privacy advocates off balance as they are forced to
defend abstract rights using loathsome examples.  But if you tune in to the
Cypherpunks mailing list (majordomo at toad.com) you can get some excellent
first hand reports from the front.

In the relatively short period since the passage of the Bank Secrecy Act,
which, among other things, obliges banks to file Suspicious Activity
Reports on its customers, banks have become virtual deputies in the
treasury department's war on uncontrolled financial transactions.  And this
war is increasingly spilling into cyberspace.

The conference underscored the fact that, paradoxically, we are heading not
toward more specific and well defined transaction monitoring regulations,
but less.  How so?  The problem with making regulations precise is that
what software algorithms can define, other algorithms can evade.  Instead,
regulation by "raised eyebrow" is becoming the norm.  Federal bank
examiners have been given significant latitude to invoke draconian
penalties against uncooperative banks.  Because bank officers have few
due-process protections under this regime, it is no surprise that most of
them have become sniveling toadies.  The objective is to insure that banks
"voluntarily" introduce even more aggressive, unpredictable, and intrusive
monitoring than the government would ever dare mandate.  And to make sure
nothing slips through the cracks, human surveillance will be supplemented
with artificial-intelligence agents that can perform pattern analysis on
the aggregate flow of electronic transactions, flagging anything remotely
suspicious.  George Orwell would be impressed.

Lest you think that all of this is motivated solely by the drug war,  a
visit to the Treasury Department's Financial Crimes Enforcement Network
(FinCEN) homepage
(http://www.ustreas.gov/treasury/bureaus/fincen/facts.html) should open
your eyes.  This battle is not just about drug prohibition, a crime the
Treasury Department would have to invent if it didn't already exist.  The
real struggle is about the future of tax compliance, and it has you in its
sights.

A famous Revolutionary War era pamphleteer, writing under the pseudonym
"Brutus", perhaps said it best 200 years ago when he wrote - "The national
government through its taxing power will introduce itself into every corner
of the city and country.  It will take cognizance of the professional man
in his office or his study;  it will watch the merchant in his store;  it
will follow the mechanic to his shop and his work, and will haunt him in
his family and his bed;  it will be the constant companion to the
industrious farmer in his labour;  it will penetrate into the most obscure
cottage;  and finally it will light upon the head of every person in the
United States.  To all these different classes of people and in all these
circumstances on which it will attend them, the language in which it will
address them will be GIVE! GIVE!"

What Brutus didn't know and what the cypherpunks foresee is that one day
strong encryption will make it impossible to spy on our activities in
cyberspace.  Heightened conflict is inevitable.  Expect the rhetoric to get
a lot hotter as the government spinmeisters labor to keep us focused on
public enemies while frantically trying to keep its hand in every citizens
pocket and its eyes on every bankbook.

# # #
COPYRIGHT CMP PUBLICATIONS 1995

Bill Frezza is president at Wireless Computing Associates and co-founder of
the online forum DigitaLiberty.  The opinions expresses are his own. Frezza
can be reached at frezza at interramp.com.

 ------------------------------------
| Wireless Computing Associates, Inc.
| 704 Stoney Hill Rd., Suite 155
| Yardley, PA 19067
| ph 215-321-0929, fax 215-321-0490
| urgent Email: frezza at radiomail.net
| bulk Email: frezza at interramp.com
 ------------------------------------

From wilcoxb at nagina.cs.colorado.edu  Tue Oct 31 18:10:09 1995
From: wilcoxb at nagina.cs.colorado.edu (Bryce)
Date: Wed, 1 Nov 1995 10:10:09 +0800
Subject: There is still no perfectly anonymous currency
Message-ID: <199511010127.SAA22368@nagina.cs.colorado.edu>

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

It occurs to me that even in an on-line-cleared system, that a 
collusion of Ursula the Underwriter and Bob the Payer can identify 
Alice the Payee by traffic analysis based on time contraints.  Alice 
has to turn in the coin that Bob gave her in order to get it on-line-
cleared *before* she can close the deal with Bob assuming that she 
believes there is a chance Bob's coin is bad (pre-spent).  So Bob 
and Ursula can do some simple traffic-analysis-style coin-watching 
over the course of several transactions between Bob and Alice.

This could become infeasible for Bob and Ursula in the case that
there are very many such transactions going on at the same time and
Alice (and some of the other payees) prudently add a traffic-analysis-
foiling delay between acceptance of Bob's coin and turning it over 
to the bank, and between receiving confirmation from the bank and 
letting Bob know that the bank said "OK".  (Of course all this, and 
in fact all conversations on this subject, presume the existence and 
proper usage of identity-protecting communication protocols between 
Alice and Ursula and between Alice and Bob.)

Now in some applications it might be a problem for Alice to add
these delays.  (She might need to complete a great many transactions
in a limited amount of time.)  In this case Alice will have to
choose between efficiency and identity-protection.  Her tactic will
further be hampered by the fact that only Ursula knows how many
similar transactions are going on at any given time.  Alice will
have to guess.

In sum, I have still not seen a proposal for an electronic currency
scheme which ensures unconditional identity-protection for both payer 
and payee.  On the other hand, if a bank allows pseudonymous accounts,
or if coin-re-paying systems can be implemented, then some lesser 
degree of identity-protection is still attainable.  On the third 
hand, if a bank allows instant, cheap, anonymous accounts or, 
equivalently, if the bank issues coins in return (or as Tony Eng has
suggested, issues "deposit-vouchers" in return) instead of accessing
the payee's account, then ensuring unconditional identity-protection 
for both parties is easy under several protocols, including the 
Chaumian Ecash protocol.  
(That is:  auto-coin-laundering via an instant, one-use anonymous 
account that you control or via a new coin or a deposit voucher
whose blinding factors you chose.)

Bryce

signatures follow

            "To strive, to seek, to find and not to yield."   

                          bryce at colorado.edu                   

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01

iQCVAwUBMJbM0vWZSllhfG25AQG1MgP/UhbGC2Afih+/hrQcjvc4lOQBAWXQ8lDL
HpMRI1002odcEQ3LX/Dy2H7+LwsnMQweVtQU3Q9Q8cVWOeSXSReoKAZinbjAvvfH
Hf7xKZcmgX4xBhRmOeLxH2/noGL5iRkjONuMfQUFE85Rkc3ilh7IQr+UC8sGLUY1
2p/tXgsFJbM=
=RzYl
-----END PGP SIGNATURE-----

From frantz at netcom.com  Tue Oct 31 18:13:28 1995
From: frantz at netcom.com (Bill Frantz)
Date: Wed, 1 Nov 1995 10:13:28 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199511010149.RAA04458@netcom3.netcom.com>

At 17:19 10/31/95 -0600, Martin Diehl wrote:
>     2. When doing time domain measurements (Hewlett Packard had some good 
>     application notes on this subject), you must consider base clock 
>     jitter.  Ill try to illustrate with a diagram:
>     
>     actual event:            V                    V
>     clock granularity:  /...../...../...../...../...../...../
>     
>     the problem is that no matter how small the basic clock unit is 
>     (symbolized by "/", above), you can't be sure how much of that unit 
>     has passed when the event (symbolized by "V", above) occurs.  For 
>     example, on the original IBM PC, clock interrupts occurred about 18.2 
>     times per second (55ms interval).  In that architecture, you can't 
>     time an event and have an uncertainty of less than 2 times 55ms

Ah, but there is a neat hack that works well if you can dedicate the whole
processor to doing the timing.  This works with systems that do not have
preemptive multi-tasking.  (Getting it to work with preemptive
multi-tasking is a harder excersize).  Credit where credit is due, I first
saw this technique used, probably in 1968, on the IBM/360 (60HZ clock) with
a pair of programs called PACER and RATER.

Monitor the clock location.  (It doesn't matter whether it is incrmented by
hardware or software.)  Run a timing loop from when it changes until it
changes again and count the number of times through the loop.  Then use the
same timing loop and count how many times the loop runs from a clock tick
to the event of interest (or from the event of interest to the next clock
tick).  Use the ratio of the two counts to interprolate between the times
you can get from the clock.

You have used the processor's instruction rate to synthesize a better clock.

Bill

From hallam at w3.org  Tue Oct 31 18:17:46 1995
From: hallam at w3.org (hallam at w3.org)
Date: Wed, 1 Nov 1995 10:17:46 +0800
Subject: Keyed-MD5, and HTTP-NG
In-Reply-To: <199511010004.TAA14640@jekyll.piermont.com>
Message-ID: <9511010201.AA01860@zorch.w3.org>

Ooops...

Just gone off and read the papers again. The Keyed MD5 proposal currently described 
in one of the drafts is indeed one of those that was suggested in the cryptobytes 
article. I remember reading another calling itself "Keyed MD5" at the time of the 
rumpus Perry refered to.

The response that had been communicated back was that the IP sec work was going to 
standard anyway despite the objections. The suggestion which had started people off 
was that of MAC_a(x) = MD5(a.x.a). Nobody ever mentioned that IP sec had changed the 
construction (which is a good thing).

The point still stands however that there will have to be more than one algorithm 
supported and that HTTP-NG cannot assume that a particular algorithm or construction 
will be used. Keyed-MD5 is still an MD5 variant, there are good reasons to think that 
a keyed digest could be constructed which would be faster than a hash function.  

	Phill

From hallam at w3.org  Tue Oct 31 18:28:30 1995
From: hallam at w3.org (hallam at w3.org)
Date: Wed, 1 Nov 1995 10:28:30 +0800
Subject: Please send cash
In-Reply-To: <9510312359.AA21087@all.net>
Message-ID: <9511010212.AA30561@zorch.w3.org>

> While HotJava prevents applets from actively opening connections that
> violate the user-selected security policy, it allows an applet to accept
> connections from anywhere.  At this point, an applet only has to use any one
> of a number of channels to communicate where it is, and have the remote end
> do the active open.

What if I start a Java applet then send it a faked TCP/IP packet from another 
host? Can I hotwire an outgoing connection that appears to be from the victim 
host?

TCP/IP connections are not really all that directed. It is only the startup 
phase that is trully directed - someone has to start a conversation.

Planned sequence of events :

Mallet:
	Send out Java applet to Alice
	Send Bob a connection request packet on port 22
	Alice's Java applet is accepting connections.
	Send Alice a "request" packet claiming to come from port 22
	Should now have an outgoing connection.

???? I'm not a TCP/IP hacker (much). I'll ask our guru tommorow after we
are done with the NSA.

		Phill

From hallam at w3.org  Tue Oct 31 18:48:37 1995
From: hallam at w3.org (hallam at w3.org)
Date: Wed, 1 Nov 1995 10:48:37 +0800
Subject: CJR returned to sender
In-Reply-To: <199511010030.QAA09462@jobe.shell.portal.com>
Message-ID: <9511010221.AA01918@zorch.w3.org>

Scott Brickner  writes:
>Dan Weinstein writes:
[unknown writes:]
>>>If anyone from MIT is reading this, it would be a real public service to 
>>>put on a web site (a) what the system used for the release of PGP is 
>>>exactly and (b) what assurances (oral, written, names & dates) was 
>>>received from State/Commerce that this was legal.
>>
>>You are assuming that because the government has chosen not to
>>prosecute MIT that they will not prosecute anyone else.  This is a
>>faulty assumption, laws are not invalidated if they are not enforced,
>>only if they are repealed or overturned.

>From what I have been told the NSA have never squeaked about the PGP server.
No correspondence whatsoever. But then again MIT has some pretty meaty
lawyers and never gives in to nuisance suits (they recently paid $2 million
to fight one). Besides I doubt the head of the CIA would be too happy with
the NSA if they went of beating up MIT. NCSA got pretty well beaten up however.

I think that at the moment they are far to wound up trying to hope the Zimmerman 
case goes away that they want to start another.

Its simply a bunch of beureacrats looking to keep their jobs after the war. Each 
time someone in congress yelps more money for "defence" you get more of those 
people. They now have to justify their pay packet. Before too long someone will 
clue in on a way to save 150 million a year. Actually they have done already but 
it takes a while for things to happen. What do you expect? The US constitution 
is not designed to create an efficient government, its meant to stop them 
getting much done.

		Phill

From markm at omni.voicenet.com  Tue Oct 31 19:07:02 1995
From: markm at omni.voicenet.com (Mark M.)
Date: Wed, 1 Nov 1995 11:07:02 +0800
Subject: Digicash on Scientific American
In-Reply-To: 
Message-ID: 

On Tue, 31 Oct 1995, Aleph One wrote:

> Another thing before I go to bed. On the November issue of Scientific 
> American the Essay column writen by Anne Eisenberg is titled "Doing 
> Busioness on the Net". Its short (one page), but metions PK crypto, 
> touches upon the dangers that online transcations pose to privacy, and 
> talks a bit about ecash. Sadly there is no mention of ITAR *sight*

I was impressed with the slant of this essay.  I remember another article
on different forms of digital cash in Popular Science where the author mentions
ecash and the only thing said about it was that it could aid drug-traffickers.
I was glad to see the article in Scientific American that gives the positive
side of ecash.  It did seem from some of the responces to the Popular Science
article that most people disagreed with the author's point of view on 
anonymous digital cash. 

`finger -l markm at omni.voicenet.com` for public key and Geek Code
Public Key/1024: 0xF9B22BA5 BD 24 D0 8E 3C BB 53 47  20 54 FA 56 00 22 58 D5
Homepage URL:http://www.voicenet.com/~markm/

From fc at all.net  Tue Oct 31 19:08:23 1995
From: fc at all.net (Dr. Frederick B. Cohen)
Date: Wed, 1 Nov 1995 11:08:23 +0800
Subject: Please send cash
In-Reply-To: <9511010212.AA30561@zorch.w3.org>
Message-ID: <9511010226.AA02469@all.net>

> > While HotJava prevents applets from actively opening connections that
> > violate the user-selected security policy, it allows an applet to accept
> > connections from anywhere.  At this point, an applet only has to use any one
> > of a number of channels to communicate where it is, and have the remote end
> > do the active open.
> 
> What if I start a Java applet then send it a faked TCP/IP packet from another 
> host? Can I hotwire an outgoing connection that appears to be from the victim 
> host?

I think so.

-- 
-> See: Info-Sec Heaven at URL http://all.net
Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

From carolann at censored.org  Tue Oct 31 20:19:09 1995
From: carolann at censored.org (Censored Girls Anonymous)
Date: Wed, 1 Nov 1995 12:19:09 +0800
Subject: If I WANNA I'M GONNA
Message-ID: <199510312105.VAA11591@mailhost1.primenet.com>

I see all the traffic analysis arguments.

They are silly. If someone wants something, they will get it.

Simple.

The only question is how long it will take.

Not if!

Just how long!

Love Always,

Carol Anne
ps Wanna argue with a loaded gun at your face? SEE!
--

Member Internet Society  - Certified BETSI Programmer  -  Webmistress
***********************************************************************
Carol Anne Braddock (cab8)  carolann at censored.org   206.42.112.96
My Homepage
The Cyberdoc
***********************************************************************
------------------ PGP.ZIP Part [017/713] -------------------
M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M
MF=O0H+*%(-S%&>S%+FS& http://dcs.ex.ac.uk/~aba/export/

From merriman at arn.net  Tue Oct 31 20:33:11 1995
From: merriman at arn.net (David K. Merriman)
Date: Wed, 1 Nov 1995 12:33:11 +0800
Subject: ecash remailer
Message-ID: <199511010417.WAA10507@arnet.arn.net>

>> Wouldn't the ability to have the bank prove that the coins were 'cashed'
>> make this all null and void? The only way this would work would be if
>> Charlie is willing to completely forego cashing in the coins, *ever*. Should
>> he cash them in later, Ed would seem to have grounds for suspicion/complain.
>
>In the scenario I suggested, Charlie never gets coins from anyone. He just
>(falsely) claims that he was supposed to have received some from Alice.

My test copy of the Ecash software logs what coins were spent - wouldn't
something like that constitute evidence that any claim was made? Failing
that, wouldn't Ed be able to tell the bank 'these coins were
misplaced/lost/damaged. please cancel them', and then re-issue any payment due?

*If* Alice really paid Ed, then he would have evidence of such, whether
Charlie's claim is valid or not. With the cash in hand, Ed should reasonably
be able to re-issue them, just as one could put a stop-payment on a check
and re-issue.

Or am I completely missing something here? (always a possibility, I suppose :-)

Dave
This is a test (3 UUE lines) of the unconstitutional ITAR - 1/713th
of the PGP executable. See below for getting YOUR chunk! 
------------------ PGP.ZIP Part [015/713] -------------------
M=$<(&L`#*IPP",(G6(,,S,`P](<2RWU96XCW86/JBYV8A\D8 at X'HB_9H#&\X
MX'PCUB.,13B"X8`R?^J-:UB.M_`U\>[#)BS&5$0C,Y#^1CS>1`\T1QTXX6!3
M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M
-------------------------------------------------------------
for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
My web page: http://www.geopages.com/CapitolHill/1148

From jirib at sweeney.cs.monash.edu.au  Tue Oct 31 21:01:11 1995
From: jirib at sweeney.cs.monash.edu.au (Jiri Baum)
Date: Wed, 1 Nov 1995 13:01:11 +0800
Subject: Important Digital Cash Question...
In-Reply-To: 
Message-ID: <199510310237.NAA00348@sweeney.cs.monash.edu.au>

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

Hello,

rah at shipwright.com (Robert Hettinga) writes:
...
> Wait, wait! I have another one. I call digital cash bankers "underwriters",
...
> So, we need a "U" name...

David HM Spector  replies:
...
> um... perhaps, Ursula the Underwriter...?
...

How about Uhura?

(Or should Uhura be Mitch, 'cause she can monitor your conversations?)

(Mitch or Witch - Woman In The CHannel?)

OK, forget it.

How about Sam the banker (Sam as in Samuel Clemens)?

Jiri
- --
If you want an answer, please mail to .
On sweeney, I may delete without reading!
PGP 463A14D5 (but it's at home so it'll take a day or two)
PGP EF0607F9 (but it's at uni so don't rely on it too much)

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

iQCVAwUBMJWL2CxV6mvvBgf5AQGbPAP/Z4wMAPokthvWygKdLEZ0vTAFTDti4sUp
4R57GrY5ZHwyJwM2bI/Xgvb30sJnVXzmHkahOouFD/6RrnW4kydouhaNFuI4Eev/
FdPxLaKz2j37U8fnC5Jo3zyRT+PZLqba6lwlcAESNNUgfEsIkM2cn3Rw72p4dnrc
Iqs5Wmo5exk=
=3MRB
-----END PGP SIGNATURE-----

From anon-remailer at utopia.hacktic.nl  Tue Oct 31 21:18:18 1995
From: anon-remailer at utopia.hacktic.nl (Anonymous)
Date: Wed, 1 Nov 1995 13:18:18 +0800
Subject: From Bill Frezza: Electronic Warfare
Message-ID: <199511010500.GAA03716@utopia.hacktic.nl>

On Tue, 31 Oct 1995, Bill Frezza  wrote:

> Attached is a column that will appear on the op-ed page of tomorrow's
> (10/30) Communications Week that was stimulated largely by a report filed

> Cypherpunks mailing list (majordomo at toad.com) you can get some excellent

list address is cypherpunks at toad.com
list manager is majordomo at toad.com
sending list mail to majordomo will not work

> cyberspace.  Heightened conflict is inevitable.  Expect the rhetoric to get
> a lot hotter as the government spinmeisters labor to keep us focused on
> public enemies while frantically trying to keep its hand in every citizens
> pocket and its eyes on every bankbook.

the entire issue is not tied to money
the gummint is not just looking for more money

can't anyone from the media get it right

better story than w$j can make though
congratulations you're more clueful than the average media stooge

From ses at tipper.oit.unc.edu  Tue Oct 31 21:34:48 1995
From: ses at tipper.oit.unc.edu (Simon Spero)
Date: Wed, 1 Nov 1995 13:34:48 +0800
Subject: W3 Self-Regulation?
In-Reply-To: 
Message-ID: 

On Tue, 31 Oct 1995, Dave Del Torto wrote:

> [Where's Tipper when you need her? Answer:]

Hey! Lay off the divine Ms. G!

There's actually a big difference between labelling and censorship, 
though there's always the danger that once material has been labelled, 
Ralph Reed and his merry gang of cross burners will try to ban 
information bearing certain labels (the ol' gateway effect).

Of course, if the labeling information isn't signed, the it's useless. 
Oh, and if people vote on labels, you really, really need secret voting 
protocols; this information can be very sensitive if it can be tied back 
to the voters.

Simon
p.s.
 What if instead of approving or banning drugs, the FDA instead just 
issued labels, and left the choices to the customer and his or her 
insurance agency...

---
(defun modexpt (x y n)  "computes (x^y) mod n"
  (cond ((= y 0) 1)   ((= y 1) (mod x n))
	((evenp y) (mod (expt (modexpt x (/ y 2) n) 2) n))
	(t (mod (* x (modexpt x (1- y) n)) n))))

From futplex at pseudonym.com  Tue Oct 31 21:58:05 1995
From: futplex at pseudonym.com (Futplex)
Date: Wed, 1 Nov 1995 13:58:05 +0800
Subject: ecash remailer
In-Reply-To: <199511010321.TAA15848@ix8.ix.netcom.com>
Message-ID: <199511010542.AAA12674@thor.cs.umass.edu>

Responding to several subthreads at once:

Dave M., I get the feeling we're talking about completely different scenarios.
What I had in mind boils down to the case of Alice laundering money through
Ed with payer (and maybe payee) anonymity, then crying "Thief !" and getting
the bank to trace Ed. Without adding anything else, it's her word against his.

Aleph, I think you raise an important objection. After the money has been
through the wash a few (dozen) times, it's hard to tell whence it came. This 
leads into Bill's point:

Bill writes:
> But as near as I can tell, _any_ merchant has that risk, because there's
> no way for Ed to distinguish between cash that Bob withdrew himself
> and cash that Bob got from someone else.  Does this mean that anybody
> who sells goods to anonymous clients is automatically a money-launderer?
> If so, either the bogus money-laundering laws have to go (yay!) 
> or laws against selling to anonymous clients will get written (boo!) 
> or selective enforcement and entrapment will become increasingly popular, 
> leading merchants to refuse to do anonymous business just to defend 
> themselves against extortionists\\\\\\\\\\\\legitimate needs of law 
> enforcement?

Indeed. But really, _everyone_ who accepts cash and disburses money is a
money launderer. When I hand a bored high school student some cash for
lemonade at a supermarket, the market launders my money. I don't have to be
strongly anonymous. Even if they checked my ID before taking my greenbacks, 
they would have no way of knowing whether those were ill-gotten gains or not.
Monetary value just isn't intrinsically good or bad, period.

Don suggests the use of receipts to counter fraudulent theft claims. But how 
are we to arrange receipts for payer-anonymous transactions ?  With paper 
cash, banker Ursula of course need not worry about double spending, so she 
doesn't have to track which bills have been spent. That makes it hard for
Alice to fraudulently (or truthfully !) accuse Louie the Launderer of theft
via this protocol, unless Alice happens to be the Treasury Dept. 

-Futplex 
Please don't cc: me on replies to the list; I get too much mail as it is.

From hfinney at shell.portal.com  Tue Oct 31 22:29:00 1995
From: hfinney at shell.portal.com (Hal)
Date: Wed, 1 Nov 1995 14:29:00 +0800
Subject: Digicash tagged with payee?
Message-ID: <199511010604.WAA25344@jobe.shell.portal.com>

I have heard it claimed that when you make a payment with Digicash ecash,
the identity of the payee is encoded or embedded into the cash somehow.
This is an anti-theft measure (among other things, perhaps).  The bank
checks that the embedded identity in deposited cash matches the account
name which is doing the deposit.

My question is, how could this be done?  How can the payor, at payment
time, without communicating with the bank, embed a payee name
irreversibly into the cash so that a thief cannot strip it out and
replace it with his own name?

Is it perhaps a matter of encrypting the cash with the public key of
the payee?  If so, how does the payor get that?  Is it provided by the
payee during the TCP connection?  Is it authenticated with a
certificate, perhaps signed by some Digicash root key?

Off-list there has been some discussion about the role of certificates in
ecash, and in cash systems in general.  It would be interesting to know
if this anti-theft provision of Digicash is actually provided by means of
a certificate.

From futplex at pseudonym.com  Tue Oct 31 22:31:50 1995
From: futplex at pseudonym.com (Futplex)
Date: Wed, 1 Nov 1995 14:31:50 +0800
Subject: W3 Self-Regulation?
In-Reply-To: 
Message-ID: <199511010617.BAA05450@thor.cs.umass.edu>

DDT writes:
# [Where's Tipper when you need her? Answer:]

Simon writes:
> Hey! Lay off the divine Ms. G!

Urgh. If I believed in a Hell, I'd expect the Parents Music Resource Center
to have its HQ there.

> There's actually a big difference between labelling and censorship, 

Agreed, to the extent that providers are not required to label their
products/services. But to my mind, the PICS software crosses the line between
labelling and censorship. In particular, it is a tool with which parents will
censor what their children encounter. 

Before Nathan Zook levels me, (hi :) let me elaborate. Such censorship seems
to be inevitable/necessary given the relationship between parents and their
children in our society. Parents are largely held liable for their
childrens' actions, while children generally are not responsible for their 
own actions. I believe this arrangement is unfair, but until/unless it
changes, parents must be given certain powers over those for whose actions 
they may be held liable.

We've hashed over this stuff several times before, so I'm not sure how much
sense it makes to reiterate it.

-Futplex 

From mark at grondar.za  Tue Oct 31 22:34:59 1995
From: mark at grondar.za (Mark Murray)
Date: Wed, 1 Nov 1995 14:34:59 +0800
Subject: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
Message-ID: <199511010614.IAA08682@grumble.grondar.za>

> In article <199510311715.TAA05821 at grumble.grondar.za>,
> Mark Murray  wrote:
> > forever {
> > 	cat /dev/random > /dev/null
> > }
> > 
> > Severely limiting most decent folk's chance at getting PGP to work.
> 
> Ideally, if two processes are trying to read /dev/random at the same time,
> both would get data at half-speed.  Doesn't it work that way already?

Ideally, yes. However most processes won't swamp (and deplete) /dev/random
like this will. Most (well-behaved) processes will (should) just take what
they need. The above loop tries quite hard to take all that is there,
so any process asking for randomness will be sharing with the above loop
on an almost byte-by-byte basis, like you suggest.

The above won't leave a "pool of randomness" to act as a buffer for user
requests, so will cause a nasty slowdown.

M
--
Mark Murray
46 Harvey Rd, Claremont, Cape Town 7700, South Africa
+27 21 61-3768 GMT+0200
Finger mark at grumble.grondar.za for PGP key

From anonymous-remailer at shell.portal.com  Tue Oct 31 22:50:02 1995
From: anonymous-remailer at shell.portal.com (anonymous-remailer at shell.portal.com)
Date: Wed, 1 Nov 1995 14:50:02 +0800
Subject: "Dr." Fred
Message-ID: <199511010627.WAA28538@jobe.shell.portal.com>

The most charitable explanation for "Dr." Fred is that
he's degenerated into the professional equivalent of
those pathetic aging former chess masters who try to 
eek out a subsistence living by charging five bucks a 
game. People often play with them out of sympathy, or 
for the novelty of having lost to a past great. It's 
part of the chess culture, and it's basically harmless 
and sort of quaint.

The difference, of course, is that its almost impossible 
to have sympathy for Dr. Fred. His hussle is for a hell 
of a lot more than subsistence. He was also never actually 
a master of his field, a fact that becomes increasingly 
obvious as our exposure to him goes on. Now he's reduced
himself to trying to collect someone else's winnings.

HotJava(tm): The Security Story

Security layer one: the language and compiler

Security layer two: verifying the bytecodes

Type information

Security level three: the class loader

Security level four: protecting the file system and network access

Summary

Bibliography

HTTP Request-Header Echoes