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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
tor-reports mailing list
tor-reports@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-reports

Reply via email to