Re: Hooking nym to wikipedia

2005-10-04 Thread Peter Clay
I'm a bit concerned by this scheme. I'm not clear at the moment whether
you're proposing imposing it on all wikipedia users or just those that
want to access via Tor?

On Mon, Oct 03, 2005 at 11:48:48AM +, Jason Holt wrote:
 * Lack of forward secrecy is indeed an issue, since our metaphorical 
 Chinese dissident must keep around her cert to continue using it, which if 
 discovered links her with all her past activities.  This is a problem even 
 if Wikipedia maps each client cert to a particular random value for public 
 display, since the attackers can simply use the stolen cert to make an edit 
 on wikipedia and then check to see if the identifier comes up the same.

There's a big useability issue with client certs, in that they are part
of a particular PC browser profile and are fiddly to move between PCs;
while being moved (e.g. USB key) or at rest on the disk they are
vulnerable to raids by the security services. I'd expect the mythical
Chinese dissident to be using netcafes rather than his/her home PC which
will have a keylogger installed on it / be taken as evidence in raids.
(e.g. http://gizmonaut.net/bits/suspect.html )

(Also, I'd expect any serious repressive regimes to simply have anyone
found using Tor taken out and shot; has this been addressed?)

Pete
-- 
Peter Clay | Campaign for   _  _| .__
   | Digital   /  / | |
   | Rights!   \_ \_| |
   | http://www.ukcdr.org

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


Re: Hooking nym to wikipedia

2005-10-04 Thread cyphrpunk
On 10/3/05, Jason Holt [EMAIL PROTECTED] wrote:

 More thoughts regarding the tokens vs. certs decision, and also multi-use:

This is a good summary of the issues. With regard to turning client
certs on and off: from many years of experience with anonymous and
pseudonymous communication, the big usability problem is remembering
which mode you are in - whether you are identified or anonymous. This
relates to the technical problem of preventing data from one mode from
leaking over into the other.

The best solution is to use separate logins for the two modes. This
prevents any technical leakage such as cookies or certificates.
Separate desktop pictures and browser skins can be selected to provide
constant cues about the mode. Using this method it would not be
necessary to be asked on every certificate usage, so that problem with
certs would not arise.

(As far as the Chinese dissident using net cafes, if they are using
Tor at all it might be via a USB token like the one (formerly?)
available from virtualprivacymachine.com. The browser on the token can
be configured to hold the cert, making it portable.)

Network eavesdropping should not be a major issue for a pseudonym
server. Attackers would have little to gain for all their work. The
user is accessing the server via Tor so their anonymity is still
protected.

Any solution which waits for Wikimedia to make changes to their
software will probably be long in coming. When Jimmy Wales was asked
whether their software could allow logins for trusted users from
otherwise blocked IPs, he didn't have any idea. The technical people
are apparently in a separate part of the organization. Even if Jimmy
endorsed an idea for changing Wikipedia, he would have to sell it to
the technical guys, who would then have to implement and test it in
their Wiki code base, then it would have to be deployed in Wikipedia
(which is after all their flagship product and one which they would
want to be sure not to break).

Even once this happened, the problem is only solved for that one case
(possibly also for other users of the Wiki code base). What about
blogs or other web services that may decide to block Tor? It would be
better to have a solution which does not require customization of the
web service software. That approach tries to make the Tor tail wag the
Internet dog.

The alternative of running a pseudonym based web proxy that only lets
good users pass through will avoid the need to customize web
services on an individual basis, at the expense of requiring a
pseudonym quality administrator who cancels nyms that misbehave. For
forward secrecy, this service would expunge its records of which nyms
had been active, after a day or two (long enough to make sure no
complaints are going to come back).

As far as the Unlinkable Serial Transactions proposal, the gist of it
is to issue a new blinded token whenever one is used. That's a clever
idea but it is not adequate for this situtation, because abuse
information is not available until after the fact. By the time a
complaint arises the miscreant will have long ago received his new
blinded token and the service will have no way to stop him from
continuing to use it.

I could envision a complicated system whereby someone could use a
token on Monday to access the net, then on Wednesday they would become
eligible to exchange that token for a new one, provided that it had
not been black-listed due to complaints in the interim. This adds
considerable complexity, including the need to supply people with
multiple initial tokens so that they could do multiple net accesses
while waiting for their tokens to be eligible for exchange; the risk
that exchange would often be followed immediately by use of the new
token, harming unlinkability; the difficulty in fully black-listing a
user who has multiple independent tokens, when each act of abuse
essentially just takes one of his tokens away from him. Overall this
would be too cumbersome and problematic to use for this purpose.

Providing forward secrecy by having the nym-based web proxy erase its
records every two days is certainly less secure than doing it by
cryptographic means, but at the same time it is more secure than
trusting every web service out there to take similar actions to
protect its clients. Until a clean and unemcumbered technological
approach is available, this looks like a reasonable compromise.

CP

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


Hooking nym to wikipedia

2005-10-03 Thread Jason Holt


Thanks to everyone who has contributed feedback, cyphrpunk in particular. Here 
are my thoughts on connecting nym to wikipedia.  I'll take feedback here 
first, then approach the WikiMedia folks.


* I believe the best solution would be for wikipedia to do the following:

  - Run an SSL server (optionally using a self-signed cert) which requires
client certificates.  This is a 4-line addition to the httpd.conf.

  - Apache (already) automatically sets an environment variable identifying
the client certificate used.  MediaWiki would map this to a random state
variable equivalent to its IP identifier.

  - When admins wish to block an IP, they follow the usual procedure, which
has a special case for the special identifiers which adds the
corresponding cert to a CRL instead of modifying the IP blacklist.  The
client will no longer be able to connect to the SSL server.

  - Optionally, wikipedia can also send its list of perma-banned IPs to the
(externally operated, but wikipedia-specific) token server, which will
then refuse to serve those IPs.

* Alternatives to this approach involve someone else setting up such an SSL 
server as a reverse proxy for en.wikipedia.org and communicating a special 
identifier to wikipedia along with the proxied data in some combination of 
HTTP headers and cookies. I quite like the simplicity of these approaches, 
which could also allow avoiding certificates entirely by allowing users to 
trade a token directly for a cookie.  But now the header/cookie is subject (on 
the proxy-wikipedia link in particular) to eavesdropping, forgery and all the 
other things SSL is designed to prevent.  So ideally, wikipedia would allow an 
SSL connection from the proxy, and might as well just accept the client certs 
or tokens directly.  Also, if we eliminate certs, tokens would then have to be 
kept around and treated as secrets in case the user needs to get cookies 
issued onto other browsers or refreshed when a browser chooses to delete the 
cookie. Certs, OTOH, have a public cert that can be passed around, and come in 
a standardized file that has browser-supported passphrase en/decryption 
support.


* Incidentally, making my apache-ssl (1.3) server reverse-proxy (impersonate, 
essentially) en.wikipedia.org is ridiculously simple.  In the httpd.conf:


  # Inside the IfModule mod_proxy.c block:
ProxyRequests Off
ProxyPass / http://en.wikipedia.org/
ProxyPassReverse / http://en.wikipedia.org/

And in the modules.conf:
  LoadModule proxy_module /usr/lib/apache/1.3/libproxy.so


-J


(Side note to Damian Gerow: our mail servers refuse to talk to each other; my 
admin claims pandora.afflictions.org is reporting its IP as 10.9.22.67 (an 
unroutable IP), which makes a validity test fail.  We'll have to find a side 
channel.)


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


Re: Hooking nym to wikipedia

2005-10-03 Thread Jason Holt


More thoughts regarding the tokens vs. certs decision, and also multi-use:

* Client certs are a pain to turn on and off.  If you select ask me every 
time before sending a client cert, you have to click half a dozen OKs per 
page.  (This could be mitigated by having Wikipedia only use the SSL server 
for edits, since they're not blocking article viewing anyway, just editing.) 
If you tell the browser to send the certificate automatically and then forget 
about it, other SSL sites can silently request it, which is particularly bad 
if you're not using tor just then.


* Using tokens directly at site login time avoids the client cert hassles. 
However, evil web servers could then collect tokens (nyms) for use at other 
sites, suggesting that each server should run its own token server.  But now 
each server has a (potentially short) list of client IPs, whereas a 
centralized token server would provide better concealment.  Obviously, if 
wikipedia is the only site that ever bothers to use nym, this is a moot point.


* Lack of forward secrecy is indeed an issue, since our metaphorical Chinese 
dissident must keep around her cert to continue using it, which if discovered 
links her with all her past activities.  This is a problem even if Wikipedia 
maps each client cert to a particular random value for public display, since 
the attackers can simply use the stolen cert to make an edit on wikipedia and 
then check to see if the identifier comes up the same.


If Wikipedia generates a new random ID for each edit, then attackers have to 
access Wikipedia internals to map the IDs back to the cert, but then, so do 
Wikipedia admins when they want to assess a user's pattern of (bad) behavior. 
Note that SSL does not (IIRC) encrypt certificates, so a passive network 
eavesdropper can associate client certs with the random IDs.  (Do the 
ephemeral modes hide the certs?)


A related approach that thwarts the network eavesdropper would be to issue a 
series of certificates which expire one per interval (hour/day/whatever, 
trading privacy against the hassle of managing lots of certs).  Then our 
dissident uses each cert in turn, securely deleting it after it expires.  The 
CA keeps a list recording all the certs issued to the same user, and when 
Wikipedia wishes to ban a user, the CA revokes all the unexpired certs for 
that user.  The CA also securely deletes expired certs from its lists, so that 
if compromised, it has merely the same list of certs found on the client 
machine, and is likewise devoid of any reference to certs used in prior 
transactions.


Of course, there are nifty cryptographic solutions to the problem of revoking 
repeat offenders without linking activities of good users.  Private 
Credentials and Idemix are the two best known examples, but both are 
complicated and patent-ridden.


-J

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


Re: Hooking nym to wikipedia (fwd)

2005-10-03 Thread Jason Holt



-- Forwarded message --
Date: Mon, 3 Oct 2005 08:32:44 -0400
From: Paul Syverson [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: cryptography@metzdowd.com
Subject: Re: Hooking nym to wikipedia

Hi Jason et al,

On Mon, Oct 03, 2005 at 11:48:48AM +, Jason Holt wrote:


More thoughts regarding the tokens vs. certs decision, and also multi-use:


[snip]


A related approach that thwarts the network eavesdropper would be to issue
a series of certificates which expire one per interval (hour/day/whatever,
trading privacy against the hassle of managing lots of certs).  Then our
dissident uses each cert in turn, securely deleting it after it expires.
The CA keeps a list recording all the certs issued to the same user, and
when Wikipedia wishes to ban a user, the CA revokes all the unexpired certs
for that user.  The CA also securely deletes expired certs from its lists,
so that if compromised, it has merely the same list of certs found on the
client machine, and is likewise devoid of any reference to certs used in
prior transactions.

Of course, there are nifty cryptographic solutions to the problem of
revoking repeat offenders without linking activities of good users.
Private Credentials and Idemix are the two best known examples, but both
are complicated and patent-ridden.



You might want to have a look at our UST (Unlinkable Serial Transactions)

It was published in ACM TISSEC

http://chacs.nrl.navy.mil/publications/CHACS/1999/1999stubblebine-serial.pdf
(or .ps)

There was also an earlier version published at Financial Crypto.
(It lacks the proofs and some improvements to the protocols)

http://chacs.nrl.navy.mil/publications/CHACS/1997/1997goldschlag-FC97.pdf
(or .ps)

1. I think it is much less complicated than the other things you raised,
   but of course has other tradeoffs.

2. The papers are it. There is no current code worth looking at.

3. Thanks for the reminder. It too is patented if not patent-ridden,
   but we should be able to cope with that. Basically you shouldn't put
   huge work in assuming that there are no encumbrances to address, but if
   you are interested given 1 and 2 after you look at it, let me
   know. I can then explain the issues regarding the patent situation.

aloha,
Paul




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