Hello! Sandy just brought it to my attention that this report I sent last month somehow never made it to any of the lists I sent it to.
Here it is, for the record. ----- Forwarded message from isis agora lovecruft <i...@torproject.org> ----- > From: isis agora lovecruft <i...@torproject.org> > Subject: October - November 2016 Report for Tor Bridge Distribution > Date: Tue, 20 Dec 2016 02:46:07 +0000 > Message-ID: <20161220024607.gf1...@patternsinthevoid.net> > To: otf-proje...@opentechfund.org, otf-act...@opentechfund.org, > tor-reports@lists.torproject.org > Cc: hdevale...@hdevalence.ca > Mail-Followup-To: otf-proje...@opentechfund.org, otf-act...@opentechfund.org, > hdevale...@hdevalence.ca > Reply-To: i...@torproject.org > > Hello, > > The following progress was made in October and November 2016: > > - Began implementing the crypto needed for the social distributor, as well as > writing documentation describing it. [0] [1] > > In light of the history of attacks on pairing-friendly curves combined with > the recent pseudo-MOV attack which solves discrete logarithms in the > embedding field of the pairing (where the embedding field is of small > degree), [2] I decided to avoid pairings altogether and use an > attribute-based credential scheme based on algebraic MACs. [3] The > construction of this scheme required a library for working with points on > an elliptic curve, [4] which Henry de Valence and I have implemented in > Rust, using a curve25519 in Edwards form. Henry has made more detailed > announcement of our curve25519-dalek library on the curves mailing list, > [5] and our documentation is also available online. [6] > > The next steps for the social distributor are to implement: > > * hashing to a point on the curve (elligator2), > * the algebraic MAC scheme, > * Schnorr-style zero-knowledge proofs of knowledge of discrete logarithms, > * a blind signature scheme, and > * (maybe) a better point (de-)compression scheme, in order to eliminate the > need to worry about the cofactor (if possible for cofactor 8). > > This may sound like a lot of work, but it really shouldn't be, now that the > library is in a somewhat usable, if not HIGHLY EXPERIMENTAL AND UNREVIEWED, > state. (On that note: we'd also like to humbly request code review. If > you're up for this, please email me.) > > This work is potentially applicable to other OTF and internet freedom > projects, including Tor (if we ever allow linking against Rust code) and > Signal. After a meeting with Trevor Perrin, we've also added to our todo > list (probably after this project is done, so with alternate funding) to > incorporate into curve25519-dalek some additional functionality required > for the Signal protocol. > > [0]: https://bugs.torproject.org/7520 > [1]: > https://people.torproject.org/~isis/papers/rBridge:%20User%20Reputation%20based%20Tor%20Bridge%20Distribution%20with%20Privacy%20Preservation.copy%20with%20notes.pdf > [2]: https://arxiv.org/pdf/1605.07746.pdf > [3]: https://eprint.iacr.org/2013/516 > [4]: https://github.com/isislovecruft/curve25519-dalek > [5]: https://moderncrypto.org/mail-archive/curves/2016/000830.html > [6]: https://docs.rs/curve25519-dalek/ > > Best Regards, > -- > ♥Ⓐ isis agora lovecruft > _________________________________________________________ > OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 > Current Keys: https://fyb.patternsinthevoid.net/isis.html > ----- End forwarded message ----- -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
signature.asc
Description: Digital signature
_______________________________________________ tor-reports mailing list tor-reports@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-reports
