On 10/3/05, Jason Holt
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 majordomo@metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://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]