Re: [tor-bugs] #7520 [BridgeDB]: Design and implement a social distributor for BridgeDB

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#7520: Design and implement a social distributor for BridgeDB
-------------------------+--------------------------------------------------
 Reporter:  aagbsn       |          Owner:     
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  BridgeDB     |        Version:     
 Keywords:  SponsorZ     |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------

Comment(by rransom):

 Replying to [comment:14 isis]:

 > Also asn and I spoke very briefly on IRC about possible implementations
 of
 > rBridge. asn thinks the crypto needs to be more widely reviewed.

 The critical piece of cryptography for rBridge is the âk-TAA (k-times
 anonymous authentication) blind signature schemeâ which can additionally
 prove knowledge of exponents and group elements satisfying certain
 equations.  The particular k-TAA scheme they recommend/require requires a
 pairing-friendly group; the pairing is the most problematic part of the
 protocol.

 > I agree,
 > mostly...though, I would note that some of the simpler propositions for
 > privacy preservation in Section 5 of the rBridge paper, such as the
 Pedersen
 > secrets [14] (essentially a "newer" version of Shamir's secret sharing
 > algorithm, where "newer" means "1992") are pretty well-established.

 They use Pedersen's ''commitment'' scheme (section 3 of the paper, on page
 3 of the PDF), not his secret-sharing scheme.  Since it's a TTS-hostile
 bitmap, I'll summarize it here, using the notation of an additive group:
 The system parameters contain two elements `G` and `H` of a group of prime
 order `q`, such that no one knows `n` such that `G = nH`.  A commitment is
 a group element `C`.  To create a commitment to an exponent `s`, the
 committer chooses a secret exponent `t` uniformly at random and computes
 `C = sG + tH`.  To âopenâ a commitment `C`, the committer discloses `s`
 and `t` satisfying the same equation.  Any two openings of a single
 commitment to different values of `s` disclose the discrete logarithm of
 `H` with respect to `G`.

 > However, I
 > would need a bit of time to read up on the Oblivious Transfer (OT)
 scheme
 > utilised [15] -- which most of the rBridge privacy preservation depends
 upon
 > -- as well as the authors of that paper's [14] updates to their protocol
 > [16][17], and more recently publishes articles on OT, ([18] for one).

 The rBridge protocol does not depend on the specific choice of OT
 protocol, and does not require that it be performed using the same
 pairing-friendly group as the rest of the protocol.

 However, I don't believe that OT is useful in rBridge.  Its purpose is to
 prevent a malicious bridge distributor from learning a user's identity,
 but a distributor could still offer the user an oblivious choice of 1000
 bridges on different ports of a single IP address, and recognize the user
 when he/she/it connects to that IP address.

 (Also, you omitted reference 18.)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7520#comment:15>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs