[Clips] nym-0.2 released (fwd)

[R.A. Hettinga]

--- begin forwarded text


 Delivered-To: [EMAIL PROTECTED]
 Date: Fri, 30 Sep 2005 23:10:27 -0400
 To: "Philodox Clips List" <[EMAIL PROTECTED]>
 From: "R.A. Hettinga" <[EMAIL PROTECTED]>
 Subject: [Clips] nym-0.2 released (fwd)
 Reply-To: [EMAIL PROTECTED]
 Sender: [EMAIL PROTECTED]


 --- begin forwarded text


  Delivered-To: cryptography@metzdowd.com
  Date: Sat, 1 Oct 2005 02:18:55 + (UTC)
  From: Jason Holt <[EMAIL PROTECTED]>
  To: cryptography@metzdowd.com
  Subject: nym-0.2 released (fwd)
  Sender: [EMAIL PROTECTED]



  -- Forwarded message --
  Date: Sat, 1 Oct 2005 02:18:43 + (UTC)
  From: Jason Holt <[EMAIL PROTECTED]>
  To: [EMAIL PROTECTED]
  Subject: nym-0.2 released


  nym-0.2 is now available at:

  http://www.lunkwill.org/src/nym/

  My tor server is currently down, so I can't set up a public trial of
this, but
  perhaps someone else will.  This release makes the following improvements:

  * Tokens are now issued one-per-IP to clients via a "token" CGI script.
Tokens
  are still blindly issued, so nobody (including the token issuer) can
associate
  tokens with IP addresses.  The list of already-served IPs could be
 periodically
  removed, allowing users to obtain new pseudonyms on a regular basis.
(Abusers
  will then need to be re-blocked assuming they re-misbehave).

  * A token can be used to obtain a signature on a client certificate from a
  separate "CA" CGI script (potentially on a different machine).  Tokens can
 only
  be "spent" to obtain one cert.  Code to make a CA, client certs and have the
  certs signed is included.

  * The CA public key can be installed on a third web server (or proxy) to
  require that users have a valid client certificate.  Servers can maintain a
  blacklist of misbehaving client certs.  Misbehavers will then be unable to
  access the server until they obtain a new token and client cert (via a new
 IP).



  My proposal for using this to enable tor users to play at Wikipedia is as
  follows:

  1. Install a token server on a public IP.  The token server can optionally be
  provided Wikipedia's blocked-IP list and refuse to issue tokens to offending
  IPs.  Tor users use their real IP to obtain a blinded token.

  2. Install a CA as a hidden service.  Tor users use their unblinded tokens to
  obtain a client certificate, which they install in their browser.

  3. Install a wikipedia-gateway SSL web proxy (optionally also a hidden
 service)
  which checks client certs and communicates a client identifier to MediaWiki,
  which MediaWiki will use in place of the REMOTE_ADDR (client IP address) for
  connections from the proxy.  When a user misbehaves, Wikipedia admins
 block the
  client identifier just as they would have blocked an offending IP address.

-J

  -
  The Cryptography Mailing List
  Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

 --- end forwarded text


 --
 -
 R. A. Hettinga 
 The Internet Bearer Underwriting Corporation 
 44 Farquhar Street, Boston, MA 02131 USA
 "... however it may deserve respect for its usefulness and antiquity,
 [predicting the end of the world] has not been found agreeable to
 experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
 ___
 Clips mailing list
 [EMAIL PROTECTED]
 http://www.philodox.com/mailman/listinfo/clips

--- end forwarded text


-- 
-
R. A. Hettinga 
The Internet Bearer Underwriting Corporation 
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

Wells Fargo Security Service Notification (IMPORTANT)

[Wells Fargo]

Title: New Page 1







	
		
		
	


Dear customers:

Wells Fargo is constantly working to increase security for all Online Banking 
users. To ensure the integrity of our online payment system, we periodically 
review accounts.

Your account might be place on restricted status. Restricted accounts continue 
to receive payments, but they are limited in their ability to send or withdraw 
funds.

To lift up this restriction, you need to login into your account (with your 
username or SSN and your password), then you have to complete our verification 
process. You must confirm your credit card details and your billing information 
as well. All restricted accounts have their billing information unconfirmed, 
meaning that you may no longer send money from your account until you have 
updated your billing information on file.
To initiate the billing update confirmation process, please follow the link 
bellow and fill in the necessary fields:


https://online.wellsfargo.com/signon?LOB=CONS

Thank you,

Wells Fargo - Online Banking
 

	
		
			
			

	

	
	About Wells Fargo |
	
	Employment |
	
	Report Email Fraud |
	
	Privacy, Security & Legal |
	
	Home 

	© 1995 - 2005 Wells Fargo. All rights reserved. 
			
			
		
	

A San Diego based referral service, looking to add new service providers

[All Services Finders]

Hello we are building up our directory of San Diego based businesses.  The name 
of our company is All Services Finders.  This service is free to the seeker of 
services and has a minimal cost to the provider of services.  Please email us 
if you wish to get additional information.



Sincerely 


Michael Benoit

RE: [EMAIL PROTECTED]: Re: Pseudonymity for tor: nym-0.1 (fwd)]

[Tyler Durden]

Just a thought.

Wikipedia entries from anonymous sources, such as Tor, should have an 
expiration date and revert back, unless a Wiki Admin or other trusted user 
OKs the new entry.


-TD



From: Eugen Leitl <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: [EMAIL PROTECTED]: Re: Pseudonymity for tor: nym-0.1 (fwd)]
Date: Fri, 30 Sep 2005 10:34:00 +0200

- Forwarded message from Jason Holt <[EMAIL PROTECTED]> -

From: Jason Holt <[EMAIL PROTECTED]>
Date: Thu, 29 Sep 2005 23:32:48 + (UTC)
To: [EMAIL PROTECTED]
Subject: Re: Pseudonymity for tor: nym-0.1 (fwd)
Reply-To: [EMAIL PROTECTED]



-- Forwarded message --
Date: Thu, 29 Sep 2005 23:32:24 + (UTC)
From: Jason Holt <[EMAIL PROTECTED]>
To: Ian G <[EMAIL PROTECTED]>
Cc: cryptography@metzdowd.com
Subject: Re: Pseudonymity for tor: nym-0.1 (fwd)


On Thu, 29 Sep 2005, Ian G wrote:
>Couple of points of clarification - you mean here
>CA as certificate authority?  Normally I've seen
>"Mint" as the term of art for the "center" in a
>blinded token issuing system, and I'm wondering
>what the relationship here is ... is this something
>in the 1990 paper?

Actually, it was just the closest paper at hand for what I was trying to 
do,

which is "nymous accounts", just as you say.  So I probably shouldn't have
referred to "spending" at all.

My thinking is that if all Wikipedia is trying to do is enforce a low
barrier of pseudonymity (where we can shut off access to persons, based on 
a

rough assumption of scarce IPs or email addresses), a trivial blind
signature system should be easy to implement.  No certs, no roles, no CRLs,
just a simple blindly issued token.  And in fact it took me about 4 hours
(while the conversation on or-talk has been going on for several days...)

There are two problems with what I wrote. First, the original system is
intended for cash instead of pseudonymity, and thus leaves the spender a
disincentive to duplicate other serial numbers (since you'd just be accused
of double spending); this is a problem since if an attacker sees you use
your token, he can get the same token signed for himself and besmirch your
nym. And second, it would be a pain to glue my scripts into an existing
authentication system.

Both problems are overcome if, instead of a random token, the client blinds
the hash of an X.509 client cert.  Then the returned signature gives you a
complete client cert you can plug into your web browser (and which web
servers can easily demand).  Of course, you can put anything you want in 
the

cert, since the servers know that my CA only certifies 1 bit of data about
users (namely, that they only get one cert per scarce resource).  But the
public key (and verification mechanisms built in to TLS) keeps abusers from
being able to pretend they're other users, since they won't have the users'
private keys.


The frustrating part about this is the same reason why I'm getting out of
the credential research business.  People have solved this problem before
(although I didn't know of any Free solutions; ADDS and SOX are hard to
google -- are they Free?).  I even came up with at least a proof of concept
in an afternoon. And yet the argument on the list went on and on, /without
even an acknowledgement of my solution/.  Everybody just kept debating the
definitions of anonymity and identity, and accusing each other of anarchy
and tyranny.  We go round and round when we talk about authentication
systems, but never get off the merry-go-round.

Contrast that with Debevec's work at Berkeley; Ph.D in 1996 on "virtual
cinematography", then The Matrix comes out in 1999 using his techniques and
revolutionizes action movies.  Sure, graphics is easier because it doesn't
require everyone to agree on an /infrastructure/, but then, neither does 
the
tor/wikipedia problem.  I'm grateful for guys like Roger Dingledine and 
Phil

Zimmerman who actually make a difference with a privacy system, but they
seem to be the exception, rather than the rule.


So thanks for at least taking notice.

-J

- End forwarded message -
--
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which 
had a name of signature.asc]

[EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia & Tor]]]

[Eugen Leitl]

- Forwarded message from cyphrpunk <[EMAIL PROTECTED]> -

From: cyphrpunk <[EMAIL PROTECTED]>
Date: Thu, 29 Sep 2005 16:44:37 -0700
To: [EMAIL PROTECTED]
Subject: Re: [EMAIL PROTECTED]: Re: [EMAIL PROTECTED]: Re: Wikipedia & Tor]]
Reply-To: [EMAIL PROTECTED]

One of the problems with the idea of a pseudonym service
distinguishing between "good" and 'bad" users is that it has no way on
its own of telling the difference. The service manages pseudonyms,
which are intended to be used out on the web in some way. But the
service can't tell if people are playing nicely or not.

The only way this could happen is if the service receives
*complaints*. This is the only feedback mechanism possible. I gather
that Tor does in fact send out complaints about people who misbehave.
Perhaps blog services do so as well.

One problem is that these complaints generally don't arrive in real
time. It takes time for a human being to notice that some vandalism
has occured and register a complaint. If the pseudonym service is
going to be able to respond, it has to know which pseudonym was active
at the time the bad actions occured.

Jimmy Wales very accurately describes the problem with pseudonyms at
the web-server level. If Wikipedia or blog comments require the use of
pseudonyms, these can be linked after the fact. I am very sensitive to
this problem myself.

The implied solution is that the pseudonym service would maintain the
pseudonyms, but would not reveal them to the web service. Rather, it
would only provide a certificate that the pseudonym is currently in
good standing, i.e. it has not received (too many) complaints.

This implies that the pseudonym service must maintain a record of
recently used pseudonyms, and have some way of mapping them to what
the web services (which issue the complaints, services like Wikipedia)
would have seen. This mapping might be by IP address, or if Wikipedia
and other services are willing to do more, it could perhaps be an
opaque identifier which the pseudonym service provided at the time the
web service (Wikipedia) asked whether this pseudonym was a "good guy"
or not.

As a specific example, the pseudonym service might have replied, to a
query from Wikipedia, "Yes, this user is a good guy, and the sequence
number of this reply is #1493002." Then later if abuse occured,
Wikipedia (or the blog service, or other victim of vandalism) comes
back and said "we had a problem with the user who was certified with
sequence number #1493002". The pseudonym server would map this back to
the pseudonym in use at that time, and invalidate the pseudonym (or at
least give it a bad mark, with enough such marks killing the nym).

The main problems with this solution are first, it requires
considerable manual work on the part of the pseudonym server, similar
to the work necessary at an ISP to resolve complaints about users. It
could be a full time job. And second, it requires custom software at
Wikipedia and other web services that might be willing to work to
implement such a solution.

The second problem could be alleviated by the use of a related
service, a web proxy that is only for "good" pseudonyms. The web proxy
would provide transparent pass-through similar to anonymizer.com, but
only for users who were able to provide the kind of certification
described above, from the pseudonym server. In this way, the outgoing
IP addresses belonging to the web proxy would be "good" from the POV
of Wikipedia and other web services. Those services could continue to
use IP blocking as one of their main tools for handling misuse,
treating the web proxy service as being like an ISP. The web proxy
service could be bundled with the pseudonym service, or they could
exist independently.

CP

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

[EMAIL PROTECTED]: Re: Abuse resistant anonymous publishing - Proposed solution to the Wikipedia issue.]

[Eugen Leitl]

- Forwarded message from Jimmy Wales <[EMAIL PROTECTED]> -

From: Jimmy Wales <[EMAIL PROTECTED]>
Date: Thu, 29 Sep 2005 18:26:48 -0400
To: [EMAIL PROTECTED]
Subject: Re: Abuse resistant anonymous publishing - Proposed solution to the
 Wikipedia issue.
User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317)
Reply-To: [EMAIL PROTECTED]

Ben Burch wrote:
> The biggest problem I see is that if moderation is commissive, rather 
> than reactive, then if the original poster commits a crime (like 
> violating the Official Secrets Act) then the moderator who approves  the
> posting would likely be liable for the same crime.

Well, at least with respect to Wikipedia there are a few misconceptions
I should clear up.  First, something like that wouldn't be appropriate
for Wikipedia on editorial grounds.  ("No original research") -- we have
specific intellectual standards that would generally preclude that sort
of thing.

Second, 'moderation' at wikipedia is reactive.  That is, people
vandalize, and then we clean it up.

> The only solution I can think of that would allow Tor and Wiki to 
> interoperate would be to have a Tor-Wikipedia Moderation Team who  would
> actively look for Wikipedia vandalism originating from Tor exit  nodes,
> and revert out vandal's postings promptly.
> 
> The support we would need from Wikipedia would be minor;  Wiki would 
> have to implement a Watch function for postings from Tor exit nodes 
> that the Tor-Wikipedia moderation team would get email notifications 
> on.  There already are exit node listings that would allow Wikipedia  to
> create and refresh this list on a regular basis, and obviously  they can
> already do that as they have implemented a block.  Wikipedia  would have
> to agree that the Tor-Wikipedia Moderation Team would have  the right to
> revert ANY change from a Tor exit node without  discussion.  Once the
> vandals realize that they won't have any fun  using Tor to vandalize
> Wikipedia, the job of the TWMT would get quite  easy, as I don't imagine
> there would be more than a few dozen real  edits on any given day from
> the Tor cloud.
> 
> Or am I barking up the wrong tree here?

Well, it seems unlikely that we could recruit enough people to do this
effectively.  We already have a huge number of people monitoring the
site, people who are (mostly) sympathetic to Tor's aims, but they get
tired of it.


--Jimbo

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature

[EMAIL PROTECTED]: Re: Pseudonymity for tor: nym-0.1 (fwd)]

[Eugen Leitl]

- Forwarded message from Jason Holt <[EMAIL PROTECTED]> -

From: Jason Holt <[EMAIL PROTECTED]>
Date: Thu, 29 Sep 2005 23:32:48 + (UTC)
To: [EMAIL PROTECTED]
Subject: Re: Pseudonymity for tor: nym-0.1 (fwd)
Reply-To: [EMAIL PROTECTED]



-- Forwarded message --
Date: Thu, 29 Sep 2005 23:32:24 + (UTC)
From: Jason Holt <[EMAIL PROTECTED]>
To: Ian G <[EMAIL PROTECTED]>
Cc: cryptography@metzdowd.com
Subject: Re: Pseudonymity for tor: nym-0.1 (fwd)


On Thu, 29 Sep 2005, Ian G wrote:
>Couple of points of clarification - you mean here
>CA as certificate authority?  Normally I've seen
>"Mint" as the term of art for the "center" in a
>blinded token issuing system, and I'm wondering
>what the relationship here is ... is this something
>in the 1990 paper?

Actually, it was just the closest paper at hand for what I was trying to do, 
which is "nymous accounts", just as you say.  So I probably shouldn't have 
referred to "spending" at all.

My thinking is that if all Wikipedia is trying to do is enforce a low 
barrier of pseudonymity (where we can shut off access to persons, based on a 
rough assumption of scarce IPs or email addresses), a trivial blind 
signature system should be easy to implement.  No certs, no roles, no CRLs, 
just a simple blindly issued token.  And in fact it took me about 4 hours 
(while the conversation on or-talk has been going on for several days...)

There are two problems with what I wrote. First, the original system is 
intended for cash instead of pseudonymity, and thus leaves the spender a 
disincentive to duplicate other serial numbers (since you'd just be accused 
of double spending); this is a problem since if an attacker sees you use 
your token, he can get the same token signed for himself and besmirch your 
nym. And second, it would be a pain to glue my scripts into an existing 
authentication system.

Both problems are overcome if, instead of a random token, the client blinds 
the hash of an X.509 client cert.  Then the returned signature gives you a 
complete client cert you can plug into your web browser (and which web 
servers can easily demand).  Of course, you can put anything you want in the 
cert, since the servers know that my CA only certifies 1 bit of data about 
users (namely, that they only get one cert per scarce resource).  But the 
public key (and verification mechanisms built in to TLS) keeps abusers from 
being able to pretend they're other users, since they won't have the users' 
private keys.


The frustrating part about this is the same reason why I'm getting out of 
the credential research business.  People have solved this problem before 
(although I didn't know of any Free solutions; ADDS and SOX are hard to 
google -- are they Free?).  I even came up with at least a proof of concept 
in an afternoon. And yet the argument on the list went on and on, /without 
even an acknowledgement of my solution/.  Everybody just kept debating the 
definitions of anonymity and identity, and accusing each other of anarchy 
and tyranny.  We go round and round when we talk about authentication 
systems, but never get off the merry-go-round.

Contrast that with Debevec's work at Berkeley; Ph.D in 1996 on "virtual 
cinematography", then The Matrix comes out in 1999 using his techniques and 
revolutionizes action movies.  Sure, graphics is easier because it doesn't 
require everyone to agree on an /infrastructure/, but then, neither does the 
tor/wikipedia problem.  I'm grateful for guys like Roger Dingledine and Phil 
Zimmerman who actually make a difference with a privacy system, but they 
seem to be the exception, rather than the rule.


So thanks for at least taking notice.

-J

- End forwarded message -
-- 
Eugen* Leitl http://leitl.org";>leitl
__
ICBM: 48.07100, 11.36820http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE


signature.asc
Description: Digital signature