diff options
author | Nick Mathewson <nickm@torproject.org> | 2007-04-15 00:29:12 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2007-04-15 00:29:12 +0000 |
commit | 3af68cc3a17df1897c74ea383911a90f0ed4864d (patch) | |
tree | 7c5e83ad998d6bbe0100c30ec347591463efba46 /doc/design-paper/blocking.tex | |
parent | b030d3d7b69bce02b6f66dc0caeec961550ffea6 (diff) | |
download | tor-3af68cc3a17df1897c74ea383911a90f0ed4864d.tar.gz tor-3af68cc3a17df1897c74ea383911a90f0ed4864d.zip |
r12371@catbus: nickm | 2007-04-14 20:01:09 -0400
Add comments to blocking.tex based on an old email from Ian, so I can get the email out of my todo folder.
svn:r9957
Diffstat (limited to 'doc/design-paper/blocking.tex')
-rw-r--r-- | doc/design-paper/blocking.tex | 25 |
1 files changed, 25 insertions, 0 deletions
diff --git a/doc/design-paper/blocking.tex b/doc/design-paper/blocking.tex index a6da81b959..eb8cfc653a 100644 --- a/doc/design-paper/blocking.tex +++ b/doc/design-paper/blocking.tex @@ -1280,6 +1280,9 @@ in the face of an adversary with limited resources. %bridge authority, in a way that's sticky even when we add bridge %directory authorities, but isn't sticky when our authority goes %away. Does this exist?) +% [[Ian says: What about just using something like hash table chaining? +% This should work, so long as the client knows which authorities currently +% exist.]] %\subsection{Discovery based on social networks} @@ -1322,6 +1325,19 @@ but we should keep both sides of the issue in mind. %Nick, want to rewrite/elaborate on this section? +%Ian suggests: +% Possession of Tor: this is totally of-the-cuff, and there are lots of +% security issues to think about, but what about an ActiveX version of +% Tor? The magic you learn (as opposed to a bridge address) is a plain +% old HTTPS server, which feeds you an ActiveX applet pre-configured with +% some bridge address (possibly on the same machine). For bonus points, +% somehow arrange that (a) the applet is signed in some way the user can +% reliably check, but (b) don't end up with anything like an incriminating +% long-term cert stored on the user's computer. This may be marginally +% useful in some Internet-cafe situations as well, though (a) is even +% harder to get right there. + + \subsection{Observers can tell who is publishing and who is reading} \label{subsec:upload-padding} @@ -1588,6 +1604,12 @@ SSL certificates. %it has received a message it does not understand (as would be the %case were it not a bridge). +% Ian suggests a ``socialist millionaires'' protocol here, for something. + +% Did we once mention knocking here? it's a good idea, but we should clarify +% what we mean. Ian also notes that knocking itself is very fingerprintable, +% and we should beware. + \subsection{How to motivate people to run bridge relays} \label{subsec:incentives} @@ -1675,6 +1697,9 @@ each bridge, so users who hear about an honest bridge can get a good copy. See Section~\ref{subsec:first-bridge} for more discussion. +% Ian suggests that we have every tor server distribute a signed copy of the +% software. + \section{Future designs} \label{sec:future} |