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

[Georg Koppen]

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.

I see, thanks.

Georg


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-reports/attachments/20170306/45d48607/attachment.sig>