isis agora lovecruft: > Georg Koppen transcribed 4.5K bytes: >> isis agora lovecruft: >>> ----- Forwarded message from isis agora lovecruft <[email protected]> >>> ----- >>> >>>> From: isis agora lovecruft <[email protected]> >>>> Subject: February 2017 Report for Tor Bridge Distribution >>>> Date: Thu, 2 Mar 2017 05:30:08 +0000 >>>> Message-ID: <[email protected]> >>>> To: [email protected], [email protected] >>>> Cc: isis agora lovecruft <[email protected]>, Henry de Valence >>>> <[email protected]> >>>> Reply-To: [email protected] >>>> Delivered-To: <[email protected]> >>>> >>>> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-reports mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-reports
