[tor-commits] [bridgedb/develop] Start explaining the modification to remove Oblivious Transfer.
isis at torproject.org
isis at torproject.org
Sat Feb 1 23:57:40 UTC 2014
commit 38cbe89f713b7d70d85576423ff33d27650b7503
Author: Isis Lovecruft <isis at torproject.org>
Date: Tue Oct 29 20:38:01 2013 +0000
Start explaining the modification to remove Oblivious Transfer.
Also add detailed, high-level description of the original usage of OT for
bridge distribution, and why this is not needed within the modified threat
model. However, it occurred to me while writing out the details that the k-TAA
blind signatures (Au, Susilo, et al.) used in the original scheme *also*
require a bilinear pairing, and are used independently to the usage of OT for
creating the zero-knowledge PoKs of valid blind signatures on user commitments
to the values representing the user's numbers of Credits (the coin-like things
generated through one's bridges not getting blocked) and the user's timestamp
for the last request for an Invite Ticket.
As such, the signature scheme must either be re-evaluated and a different
scheme used, or else we likely do not save any implementation overhead by
ripping out the Oblivious Transfer (although doing so *does* still save on the
rather high computational and network bandwidth complexities involved in OT).
---
doc/proposals/XXX-bridgedb-social-distribution.txt | 237 +++++++++++++++++---
1 file changed, 209 insertions(+), 28 deletions(-)
diff --git a/doc/proposals/XXX-bridgedb-social-distribution.txt b/doc/proposals/XXX-bridgedb-social-distribution.txt
index 541daca..cd211c6 100644
--- a/doc/proposals/XXX-bridgedb-social-distribution.txt
+++ b/doc/proposals/XXX-bridgedb-social-distribution.txt
@@ -159,9 +159,88 @@ Status: Draft
XXX finishme
- 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.)
+**** Which Bridges a User is being given
+
+
+ o How many credits a User has
+
+** IV.A. Modifications
+
+ The original rBridge scheme is modified to model BridgeDB as a potential
+ malicious actor. Protecting against this at this point in time is too
+ costly, both in terms of development time, as well as in network bandwidth
+ and computational overhead. Instead, prioritization should be placed on
+ eliminating BridgeDB's ability to obtain a social graph for Tor bridge
+ users, as this is not information it currently possesses.
+
+ The rBridge scheme utilises 1-out-of-m Oblivious Transfer (OT) to allow
+ BridgeDB to blind a set of m Bridges, letting U pick (and thus learn the
+ address of) at most one out of the m Bridges. Think of it like a stage
+ magician waving a fanned deck of cards face down, and asking an audience
+ member to "pick a card! any card!" While the authors of the original paper
+ choose Naor and Pinkas' 1-out-of-m OT scheme [2] for its efficiency, they
+ failed to specify which of Naor and Pinkas' OT schemes ― as there are four
+ within the referenced paper and several more described elsewhere. For the
+ sake of continuing the argument against their recommendations to use OT
+ within the social bridge distribution scheme, it is presumed that the
+ rBridge authors were referring to the round-optimal 1-out-of-N oblivious
+ transfer scheme in §4 of that paper.
+
+ During the OT process, for each Bridge in m, BridgeDB creates a Blind
+ Signature of the Bridge and tags each signature to its corresponding
+ Bridge, so that if U chooses that Bridge, she will also recieve the
+ signature. The signature schemes utilised is Au et al.'s k-TAA Blind
+ Signature scheme, [8] which requires a bilinear pairing (XXX what type?)
+ and is q-SDH secure in the standard model. That k-TAA scheme is chosen
+ because it is compatible with Zero-Knowledge Proofs-of-Knowledge (ZKPoK),
+ such that ZKPoK may be made for k-TAA signatures, as well as for
+ Commitments. Additionally, Au et al.'s k-TAA signature scheme is a
+ modification to that proposed by Camenisch and Stadler, i.e. it allows for
+ signatures on message vectors, provided that a nonce is included with the
+ message vector. See §VII.B for an open research question regarding k-TAA
+ signature schemes.
+
+ Next, U creates a Pedersens Commitment (CMT) to the total amount of Credits
+ owned by U, and another commitment to the last time that U requested an
+ Invite Ticket. For each of these commitments, U obtains from BridgeDB
+ another k_-TAA blind signature on the commitment. Then, U constructs her
+ own Credential, consisting of the Bridge's tagged blind signature, the
+ blind signature on each of the commitments, and a hash of the nonce that
+ used as the blinding factor. (The hash of the nonce is included so that
+ multiple users may not collude to swap portions of their Credentials by
+ using the same blinding factor.) The Fiat-Shamir transformation is then
+ used to convert the aformentioned ZKPoK scheme into a Zero-Knowledge
+ Non-Interactive Proof-of-Knowledge (NIPK) scheme. With this, U send to D
+ a Proof of their Credential, without revealing any of its contents.
+
+ Every so often, the User requests that BridgeDB update their Credential
+ with recently earned tokens. XXX finish describing this process
+
+ When one of U's Bridges is "blocked", U notifies BridgeDB of the "block"
+ and, likely, if she has enough Credits to afford it, requests a new bridge.
+ In the original rBridge design, BridgeDB is only to acknowledge requests
+ for new bridges after confirming that the Bridge is indeed blocked.
+
+ This is where the rBridge design begins to do a bit of handwaving. Either
+ that, or they neglected both to put sufficient effort into defining the
+ term "blocked", as well as enough thought into precisely how BridgeDB might
+ check this. Take for example a User behind a corporate firewall which
+ blocks undentified encrypted protocols: that User will report her Bridges
+ as "blocked" ― and they are, for her at least ― though for everyone else
+ they work just fine. BridgeDB can easily check Bridge reachability from
+ the location of BridgeDB's server, and possibly can check bridge
+ reachability from various network vantage points around the world (though
+ doing this without *causing* the Bridge to become blocked when checking
+ from censoring regions can quickly become quite complex). [9]
+
+[#]: Au, Man Ho, Willy Susilo, and Yi Mu.
+ "Proof-of-knowledge of representation of committed value and its
+ applications." Information Security and Privacy.
+ Springer Berlin Heidelberg, 2010.
+ http://web.science.mq.edu.au/conferences/acisp2010/program/Session%2010%20-%20Public%20Key%20Encryption%20and%20Protocols/10-04-AuSM10acisp.pdf
+
+* V. Design
+** V.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. [1] The
@@ -181,28 +260,79 @@ Status: Draft
three Bridges, then 1-out-of-m OT is run three times: for each time, the
following steps are taken:
-* IV. Design
+ 1. User picks a set of m nonces and uses them to generate point in the
+ group G__1 via:
-** IV.A. Overview
+ R
+ yâ±¼Ì âŸµâ€•â€• ℤ*â‚š, where 1 ≤ j ≤ m
- 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
- reasons for deferring implementation of §V include:
+ 2. User computes a Non-Interactive Proof-of-Knowledge (NIPK) of the set
+ of nonces in the following manner:
- - Adding a simpler out-of-band distribution of bridges. Requiring users to
- copy+paste Bridge lines into their torrc is ridiculous.
+ ⎧ ⎛ ₘ ⎞ ₘ ⎡ yâ±¼Ì⎤ ⎫
+ ᴨ₀ = NIPK ⎨ ⎜{yâ±¼Ì}ⱼ₌â‚⎟: ∀ⱼ₌â‚⎢ Yâ±¼Ì = ɡ₠⎥ ⎬
+ ⎩ ⎠⎠⎣ ⎦ âŽ
- - XXX
+ ⎛ ₘ ⎞
+ and sends ⎜{Yâ±¼Ì}ⱼ₌₠⃦ ᴨ₀⎟ to BridgeDB.
+ ⎠âŽ
- Modifications:
+ 3. BridgeDB verifies the NIPK of the set of nonces, ᴨ₀, and then created
+ a one-time keypair:
- - Remove OT, keep blind signatures and Pedersen's Commitments.
+ R ₛₖâ°
+ skⰠ⟵―― ℤ*ₚ, pkⰠ= h
- XXX finishme
+ For each available bridge Bâ±¼, BridgeDB randomly selects
+
+ R
+ eⱼ̊,yⱼ̎ ⟵―― ℤ*ₚ,
+
+ computes 1
+ ―――――――――
+ ⎛ yⱼ̎ Bâ±¼ ⎞ eⱼ̊ + ₛₖâ°
+ Aⱼ̊ = ⎜ gâ‚€gâ‚ Yâ±¼Ìg₃ ⎟
+ ⎠âŽ
+
+ and tags (Aⱼ̊,eⱼ̊,yⱼ̎) to Bⱼ.
-** IV.C. Data Formats
+ 4. After OT… ZKNIPK… XXX
-*** 1. User Credential
+ Specifically, the 1-out-of-m OT scheme used within the "Part V: rBridge
+ with Privacy Preservation" section of the paper is described in
+ "Efficient oblivious transfer protocols" by M. Naor and B. Pinkas. [2] It
+ requires the use of a bilinear group pairing on a Type-3 supersingular
+ elliptic curve.
+
+ Unfortunately, there are very few FLOSS libraries which currently exist
+ for pairing-based cryptography. The one used in the benchmarking section
+ of the rBridge paper is libpbc [3] from Stanford University. Several
+ cryptographers have offhandedly remarked to me that I should not use this
+ library in any deployed system. When I mentioned the need for a vetted
+ pairing-based cryptographic library to Dr. Tanja Lange, she replied that
+ she has a graduate student working on it -- though when this new library
+ will be complete is uncertain.
+
+ libpbc has Python bindings, although pypbc [4] is quite incomplete and
+ only in py3k. Additionally, pypbc requires dynamic library overloading of
+ the shared object libraried for both libpbc and libgmp (the Gnu
+ Multi-Precision library, [5] which allows for calculations of arbitrary
+ precision on floats).
+
+ Rather than waiting for Dr. Lange's student to complete the new library,
+ I propose spending some small amount of time (not more than a couple
+ weeks) creating Python2 bindings for libpbc. From my experience, the
+ simplest, least error-prone method for creating Python bindings to C
+ libraries (and with the least amount of effort/knowledge of internal
+ Python functions involved) is to use CFFI. [7]
+
+ - Pedersens' Commitments
+
+ - For ZKPoK
+
+** V.C. Data Formats
+
+*** 1. User Credential
A Credential is a signed document obtained from BridgeDB. It contains all
of the state required to verify honest client behavior, and is formatted
@@ -294,22 +424,73 @@ Status: Draft
meeting in München, and he agreed that little-t tor isn't where this
code should go.
+** VI.B. Anonymous Authentication/Signature Schemes?
+
+ As the property of conditional anonymity of k-TAA blind signatures is not
+ utilised in any version of the social bridge distribution design, some
+ research should be done on other Anonymous or Partial signature schemes
+ which allow signatures to be made on message vectors. The k-TAA
+ signature scheme used in rBridge, designed by Au et al., [XXX] was based
+ off of one of Camenisch and Lysyanskaya's signature schemes. (Which one?)
+
+ Of particular interest, the cryptologists Camenisch and Lysyanskaya have
+ several schemes for various types of anonymous signatures, with varying
+ properties, as well as "A Formal Treatment of Onion Routing." [XXX] I am
+ under the impresseion that when they say "anonymous" they mean in the
+ strong sense (versus other cryptologists who attempt to design signature
+ schemes with "revocable anonymity", for example, trusted Centralised-PKI
+ Anonymous Proxy Signature schemes, or signature schemes with "anonymity"
+ that is revocable by a third party). [XXX]
+
+ Specifically, one paper, "Randomizable Proofs and Delegatable Anonymous
+ Credentials" by Camenisch and Lysyanskaya could be applicable to
+ simultaneously ensuring all of the following properties for Invite
+ Tickets:
+
+ * The Unlinkability of a generated Invite Ticket to one used later for
+ registration.
+ * Strong Anonymity for the holders of such Invite Tickets and for their
+ eventual recipients. Many "unlinkable token" schemes which rely on
+ blind signatures, i.e. Chaum's tokens, remain vulnerable to a
+ particular deanonymisation attack if the Signer is modelled as a
+ "curious" or malicious entity who stores records of the protocol
+ steps for blind signatures. [XXX explain]
+ * Unforgeability
+ * Verifiability
+
+* VII. Dependencies Upon Other Tor Software
+** VII.A. Tor Controllers
+*** 1. Proposal #199: Integration of BridgeFinder and BridgeFinderHelper
+
+ The client-side code of BridgeDB will essentially be acting as a
+ BridgeFinder, and thus BridgeDB will require a client-side mechanism for
+ communication with various Tor Controllers. This is necessary in order to
+ present a discovery mechanism whereby a Tor Controller may learn the
+ current number of Credits and Invite Tickets available to a User, and may
+ display this information in some meaningful manner.
+
* References
-[0]: http://www-users.cs.umn.edu/~hopper/rbridge_ndss13.pdf
-[1]: https://twistedmatrix.com/documents/current/api/twisted.protocols.memcache.MemCacheProtocol.html
-[2]: http://stackoverflow.com/a/5162203
-[3]: http://findingscience.com/twisted/python/memcache/2012/06/09/txyam:-yet-another-memcached-twisted-client.html
-[4]: https://pypi.python.org/pypi/txredis
-[5]: https://github.com/fiorix/txredisapi
-[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."
+[0]: Ayad, Hanan. "Growth Rate of the Binomial Coefficient."
+ Lecture Notes on SYDE423 - Computer Algorithm Design and Analysis.
+ University of Waterloo, Canada, 2008.
+ http://www.hananayad.com/teaching/syde423/binomialCoefficient.pdf
+[1]: http://www-users.cs.umn.edu/~hopper/rbridge_ndss13.pdf
+[2]: 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/7520-social-dist-design:/doc/papers/naor2001efficient.pdf
-
+[3]: https://crypto.stanford.edu/pbc/
+ http://repo.or.cz/r/pbc.git
+[4]: https://www.gitorious.org/pypbc/pages/Documentation
+ git at gitorious.org:pypbc/pypbc.git
+[5]: http://gmplib.org/
+[6]: https://metrics.torproject.org/formats.html#descriptortypes
+[7]: https://bitbucket.org/cffi/cffi
+[8]: Au, Man Ho, Willy Susilo, and Yi Mu. "Constant-size dynamic k-TAA."
+ Security and Cryptography for Networks.
+ Springer Berlin Heidelberg, 2006. 111-125.
+ http://ro.uow.edu.au/cgi/viewcontent.cgi?article=10257&context=infopapers
+[19]: https://trac.torproject.org/projects/tor/ticket/6396#comment:16
More information about the tor-commits
mailing list