commit 578abc670ad7e9576f9977d78584a2c8779184c0 Author: Isis Lovecruft <isis@torproject.org> Date: Tue Oct 22 02:42:18 2013 +0000 Update social bridge distributor proposal to include terminology. * ADD beginning of threat model as well. * ADD defⁿ table for constants/variable names in doc/proposal/XXX-bridgedb-social-distributor.txt. --- doc/proposals/XXX-bridgedb-social-distribution.txt | 101 ++++++++++++++++---- 1 file changed, 85 insertions(+), 16 deletions(-) diff --git a/doc/proposals/XXX-bridgedb-social-distribution.txt b/doc/proposals/XXX-bridgedb-social-distribution.txt index 199302c..538f6ae 100644 --- a/doc/proposals/XXX-bridgedb-social-distribution.txt +++ b/doc/proposals/XXX-bridgedb-social-distribution.txt @@ -16,7 +16,7 @@ Status: Open such malicious users and/or censoring entities from joining the pool of Tor clients who are able to receive distributed bridges. -* II. Motivation and Problem Scope +* II. Motivation & Problem Scope As it currently stands, Tor bridges which are stored within BridgeDB may be freely requested by any entity at nearly any time. While the openness, that @@ -69,9 +69,72 @@ Status: Open roughly 1000 bridges in the Email Distributor's pool, distributing 3 bridges per email response, -* III. Design +* III. Terminology & Notations +** III.A. Terminology Definitions + + User := A client connecting to BridgeDB in order to obtain bridges. + +** III.B. Notations + +|--------------------+---------------------------------------------------------------------------------------------| +| Symbol | Definition | +|--------------------+---------------------------------------------------------------------------------------------| +| U | A user connecting to BridgeDB in order to obtain bridges, identified by a User Credential | +| D | The bridge distributor, i.e. BridgeDB | +| Gᵐᵃˣ | Upper limit (maximum) number of bridge users for a bridge Bᵢ | +| Gˢᵗᵃʳᵗ | Number of starting users | +| Gᵃᵛᵍ | Average number of users per bridge | +| M | Fraction of users which are malicious | +| B | A bridge | +| {B₁, …, Bᵢ, …, Bₖ} | The set of bridges assigned and given to user U | +| k | The number of bridges which have been given to user U | +| Tᵐⁱⁿ | The minimum time which a bridge must remain reachable | +| Tᶜᵘʳ | The current time, given in Unix Era (UE) seconds notation (an integer, seconds since epoch) | +| Tᵐᵃˣ | The upper bound on the time for which a user U can earn coins from Bᵢ | +| τᵢ | The time when bridge Bᵢ was first given to user U | +| tᵢ | The time from when U was first given Bᵢ to either Tᶜᵘʳ or ßᵢ, whichever is greater | +| ßᵢ | The time when bridge Bᵢ was first considered blocked; if not blocked, ßᵢ = 0 | +| ϕ | Total coins owned by user U | +| φᵢ | The coins which user U has earned thus far from bridge Bᵢ | +| ϱᵢ | Rate of earning coins from bridge Bᵢ | +| λᵢ | The probability that bridge Bᵢ has been blocked | +| ω | The last time that U requested and Invite Ticket from D | +|--------------------+---------------------------------------------------------------------------------------------| + +** III.C. Unicode characters + +* III. Threat Model + + In the original rBridge scheme, there are two separate proposals: the first + does not make any attempt to hide information such as the user's (U) + identity, the list of bridges given to U, the from BridgeDBBridgeDB is + + In our modifications to the rBridge social bridge distribution scheme, + BridgeDB is considered a trusted party, that is to say, BridgeDB is + assumed to be honest in all protocols, and no protections are taken to + protect clients from malicious behaviour from BridgeDB. + +** III.A. Modifications -** III.A. Overview + + + Modification: allow BridgeDB to be a malicious actor (protecting against it + at this point is too costly, instead we want to eliminate BridgeDB's + ability to obtain a social graph for Tor bridge users.) + + +*** 1. BridgeDB is permitted to know the following information: + + + + + XXX finishme + + + +* IV. Design + +** IV.A. Overview As mentioned, most of this proposal is based upon §IV of the rBridge paper, which is the non-privacy preserving portion of the paper. [0] The @@ -88,15 +151,7 @@ Status: Open XXX finishme -** III.B. Threat Model - - Modification: allow BridgeDB to be a malicious actor (protecting against it - at this point is too costly, instead we want to eliminate BridgeDB's - ability to obtain a social graph for Tor bridge users.) - - XXX finishme - -** III.C. Data Formats +** IV.C. Data Formats *** 1. User Credential @@ -136,9 +191,9 @@ Status: Open *** XXX other formats -* IV. Databases +* V. Databases -** IV.A. Scalability Requirements +** V.A. Scalability Requirements Databases SHOULD be implemented in a manner which is ammenable to using a distributed storage system; this is necessary because certain types of data @@ -214,6 +269,13 @@ Status: Open XXX evaluation on data by calling the sha1 for a serverside Lua script [#] [#]: http://redis.io/commands/evalsha + XXX mediawiki notes and references on switching to redis + [#]: https://www.mediawiki.org/wiki/Redis + + XXX using redis as a message queue for job scheduling + [#]: http://www.restmq.com/ + + **** 2.a. Data Structures which should be stored in a RDBMS - User Credentials @@ -222,9 +284,9 @@ Status: Open - Spent Credits -* IV. Open Questions +* VI. Open Questions -** IV.A. In which component of the Tor ecosystem should the client application code go? +** VI.A. In which component of the Tor ecosystem should the client application code go? *** 1. Should this be done as a Pluggable Transport? @@ -290,3 +352,10 @@ Status: Open [6]: https://github.com/andymccurdy/redis-py/ [7]: http://www.dr-josiah.com/2012/03/why-we-didnt-use-bloom-filter.html [8]: http://redis.io/topics/data-types §"Strings" + +[#]: Naor, Moni, and Benny Pinkas. "Efficient oblivious transfer protocols." + Proceedings of the twelfth annual ACM-SIAM symposium on Discrete algorithms. + Society for Industrial and Applied Mathematics, 2001. + http://www.wisdom.weizmann.ac.il/%7Enaor/PAPERS/eotp.ps + https://gitweb.torproject.org/user/isis/bridgedb.git/tree/refs/heads/feature... +