// COMPLETE THREAD

Authentication vs encryption: CPs on the web

3 expanded posts ยท every known parent and child

NODE c71f18a5Authentication vs encryption: CPs on the web
-----BEGIN PGP SIGNED MESSAGE-----

I notice in these discussions of security on the web that the topic blurs
back and forth between authentication and encryption.  Particularly when
discussing using MIME with security extensions to "secure" a document by
pre-signing it, this form of security does not add privacy.  It does
provide a useful service by allowing you to verify authorship, but my
interests are in using cryptography to protect privacy.  I think it is
useful to keep a clearer distinction between these.

I notice that the people who come to this topic from an institutional
point of view tend to be more interested in the authentication aspects.
This seems to fit better into the control-oriented mindset.  With
authentication you can track what people are doing better; non-repudiable
signatures could actually work in some ways against the signer.  I think
that may be one reason Phil Zimmermann is famous for not signing his
messages. :-)  But encryption can actually work against institutional
interests (compared to individual ones) by making it harder to keep track
of people's activities.

I exchanged email on this with Vint Cerf during the PEM standardization
process.  I objected to the fact that with PEM you could not encrypt a
message unless you signed it.  Now of course you can always fake the
signature if you need to but the principle seemed skewed to me.  Cerf
honestly could not understand why you would ever want to do this.  What
security could there be if the message were not signed, he wondered.
To me the issues are separate.  Encryption is used to make sure the
message is seen by only those for whom it is intended, and signatures are
used to verify the source of the message.  The choice of which of these
two transformations to apply should be up to the users.

I don't speak for other cypherpunks, but my interests with regard to web
security extensions would lie in the following areas.  I want to be able
to use the web and maintain my privacy.  I don't want snoopers on the net
or on my local machine to know which web sites I visit or what material I
download.  (This ties into the electronic cash issue - what use is
"anonymous" cash if everyone can see where I'm spending it and what I'm
buying?)  I also want to be able to hide my identity from the web servers
themselves, at least if this is mutually agreeable.  If a server wants to
accept only authenticated connections where it knows who the users are
that it is serving, fine.  But I want the options to be there.

I want to be able to make payments to access and download information
while protecting my privacy.  I don't want to be put onto mailing lists
or get my name into databases of people who like X without my permission.
This implies a range of payment mechanisms including credit cards,
digital checks, and digital cash.  And it also requires the privacy and
anonymity features above.

I want these features to be a matter of mutual negotiation between
client and server.  The protocols should not build in veto power for
either side over how much privacy the transaction includes (although
either side may choose not to participate if mutually agreeable terms
can't be worked out).  And therefore these features should not be
restricted to just a small fraction of transactions, where we drop into
"secure mode" momentarily so I can send my credit card number.  I want to
be in secure mode all the time.

This is IMO the standard cypherpunks wish list as applied to the WWW.
But it does not seem to match up with either the commercial or
institutional interests which are driving the standards process.  I
hope those CP's who are involved in these efforts can work to spotlight
the need for individual privacy.  We should give as much power, choice,
and control as possible to the individual end-users of the web.
Otherwise privacy is going to be very difficult to maintain in this
world of electronic commerce.

Hal Finney
hfinney@shell.portal.com

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

iQBVAwUBLu3dHRnMLJtOy9MBAQGZlwH+PYN4FahcHflm4XFPkaJE3h/QLY3lMZV5
BY4U7w7OwpVSTEUqDKd7SvjIg4tt14QI/DGGj0jyHbIS9lWew8U3rQ==
=QbAD
-----END PGP SIGNATURE-----
NODE badc2886Re: Authentication vs encryption: CPs on the web
With all due respect, I disagree with your assessment.
Anonymity is a job, and we should build small tools to do jobs.  It is
my feeling that building anonymity into the web will make the
protocols more complex than they need to be.

	There is no anonymity in mail, but we have anonymous mail of
varying privacy.  I suspect mixmaster will greatly enhance that.  To
get privacy in the web, build a web remailer on top of the CERN or TIS
HHTPd proxies.  Encrypt between you & the proxy, let the proxy go out.

Adam


| This is IMO the standard cypherpunks wish list as applied to the WWW.
| But it does not seem to match up with either the commercial or
| institutional interests which are driving the standards process.  I
| hope those CP's who are involved in these efforts can work to spotlight
| the need for individual privacy.  We should give as much power, choice,
| and control as possible to the individual end-users of the web.
| Otherwise privacy is going to be very difficult to maintain in this
| world of electronic commerce.
| 
| Hal Finney
| hfinney@shell.portal.com

-- 
"It is seldom that liberty of any kind is lost all at once."
						       -Hume
NODE 34df4951Re: Authentication vs encryption: CPs on the web
-----BEGIN PGP SIGNED MESSAGE-----

Adam Shostack <adam@bwh.harvard.edu> writes:

>	With all due respect, I disagree with your assessment.
>Anonymity is a job, and we should build small tools to do jobs.  It is
>my feeling that building anonymity into the web will make the
>protocols more complex than they need to be.

I don't think this is necessarily the case.  Anonymity is often a matter
of _not_ stamping identification onto a packet.  Rather than complicating
protocols it will often just be a matter of having options not to include
certain fields.  For example, the current HTTP has an option to send a
user name when the client makes connections.  I have heard that the
Netscape client sends this and has no switch to turn it off.  You can put
in a fake name (or none) but then when you want to send email your reply
address is wrong.  This is an example where support for privacy should be
in the client and can't really be added on.

>	There is no anonymity in mail, but we have anonymous mail of
>varying privacy.  I suspect mixmaster will greatly enhance that.  To
>get privacy in the web, build a web remailer on top of the CERN or TIS
>HHTPd proxies.  Encrypt between you & the proxy, let the proxy go out.

I think this is a fine idea if this could work.  The way proxy support
works now, the client connects to the proxy and then sends it the URL.
This means that the proxy knows which clients are connecting to which web
pages and must be trusted to keep this private.  What you need is a way
of chaining proxies such that no one proxy sees both the client and
server addresses.  This is what we have with the remailers.  But again
this would appear to require changes to the clients and corresponding
protocols.

Perhaps it would work to have a local trusted proxy running right on your
machine which implements the connection to a chain of web remailers.  You
can run vanilla clients with their nice UI's and other hot features, and
all of your net accesses go through your local proxy which cleans them up
and uses chaining for access.  This sounds like a doable project which
would be worth exploring.

Hal

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

iQBVAwUBLu4EARnMLJtOy9MBAQENJwIAvAM5rzAog54rLTmDy8wGBxJsxk4XfIYE
rGXif7AUrFwx+u1IeDnjQxNs8cul/1S/g02/rsyVKyCdT0dSfUCzoA==
=ZvjT
-----END PGP SIGNATURE-----