[tor-reports] Fwd: February 2017 Report for Tor Bridge Distribution

[isis agora lovecruft]

Georg Koppen transcribed 4.5K bytes:
> isis agora lovecruft:
> > ----- Forwarded message from isis agora lovecruft <isis at torproject.org> -----
> > 
> >> From: isis agora lovecruft <isis at torproject.org>
> >> Subject: February 2017 Report for Tor Bridge Distribution
> >> Date: Thu, 2 Mar 2017 05:30:08 +0000
> >> Message-ID: <20170302053008.GA21919 at patternsinthevoid.net>
> >> To: otf-projects at opentechfund.org, otf-active at opentechfund.org
> >> Cc: isis agora lovecruft <isis at patternsinthevoid.net>, Henry de Valence <hdevalence at hdevalence.ca>
> >> Reply-To: isis at patternsinthevoid.net
> >> Delivered-To: <isis at patternsinthevoid.net>
> >>
> >> Hello!
> >>
> >> My apologies for missing a January report.  Much of January was spent,
> >> unfortunately, dealing with the personal repercussions of an unexpected EO.
> >>
> >>
> >> The following progress was made in (late) January through February 2017:
> >>
> >>  - The specification for elliptic curve zero-knowledge proof-of-knowledge of
> >>    discrete logarithm equality was laid out in writing.  We also shared this
> >>    construction publicly with other cryptographers on the Trevor Perrin's
> >>    curves mailing list, [0] since both Tony Arcieri of Chain and George
> >>    Tankersley of Cloudflare were looking to use the same construction.
> >>
> >>  - Outlined code for the above zero-knowledge proofs, and refactored some of
> >>    the algebraic MAC and anonymous credential code.
> >>
> >>  - Begun setting up domain fronting for BridgeDB.
> >>
> >>  - More detailed documentation on our elliptic curve library,
> >>    curve25519-dalek, as well as progress on the paper/specification for the
> >>    cryptographyic requirements of our bridge distribution scheme. [1]
> >>
> >>  - Extended functionality for curve25519-dalek to ease implementation of the
> >>    Elligator2 birational map (which we require) and other features necessary
> >>    for a potential external implementation of VXEdDSA (which is useful to
> >>    Signal and other projects). [2]
> >>
> >>  - Finished a ~~beta~~ implementation of Decaf [3] for curve25519. [4]  Since
> >>    we know of no other implementations which compiles, we are looking forward
> >>    to further testing and review.  NCC Group has potentially (and generously)
> >>    offered to audit our cryptographic work, since (as mentioned above) other
> >>    companies are intending to use it.  For now, we'll call it extremely
> >>    yolocrypto beta, and base our prototype off of it.
> >>
> >>  - Finished the API for new Bridge Distributors and deployed to production. [5]
> 
> That's a bit dense for me. Could you elaborate what e.g. "deployed in
> production" means? Can user use that new feature now? If so, how? Or can
> devs test it? And I am confused about "Finished" as well with the link
> to distribute.py because that file did not get touched for almost two years.

Hey Geko,

The code was written during the period when I was waiting for the OTF
grant to go through.  (I had to switch from being a Fellow to a Project
for some bureaucratic reasons, and that delayed the grant process by about
a year.)  I deployed it about a month after the grant started, but somehow
forgot to bill for it, which I just noticed because I did a survey just
now of the work remaining and noticed the discrepancy between my time
tracker and past invoices.  Sorry for the confusion!

Developers can use this abstraction to build new distributors (for
example, a Twitter bot which sends out bridges), but… frankly, that would
be a little silly.  The distributor we're building right now (once the
version with the anonymous credentials is finished) basically renders all
the other distributors obsolete.  That is, given one that uses domain
fronting for censorship resistance and automates getting bridges with
little-to-no user interaction, I'm not sure why another developer would
want to build something which is easier to both scrape and block.

This isn't the part of distribution which hooks up to Tor Browser, which
(IIRC) requires the domain fronted distributor, that's deliverable #11 in
the OTF Project contract.  For that one, I've only gotten as far as
spending some hours reading the meek documentation and looking at
AppEngine docs.

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-reports/attachments/20170302/eb17c29d/attachment.sig>