[tor-reports] Fwd: Fwd: December 2016 Report for Tor Bridge Distribution

isis agora lovecruft isis at torproject.org
Thu Mar 2 05:31:03 UTC 2017


----- Forwarded message from isis agora lovecruft <isis at torproject.org> -----

> From: isis agora lovecruft <isis at torproject.org>
> Subject: Fwd: December 2016 Report for Tor Bridge Distribution
> Date: Thu, 2 Mar 2017 03:54:41 +0000
> Message-ID: <20170302035441.GB32522 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>
> 
> (Forwarding because I'm not entirely certain whether that last report actually
> made it to the list… the Mailer Daemon sent me a rejection that I've only just
> noticed.)
> 
> ----- Forwarded message from isis agora lovecruft <isis at patternsinthevoid.net> -----
> 
> > From: isis agora lovecruft <isis at patternsinthevoid.net>
> > Subject: December 2016 Report for Tor Bridge Distribution
> > Date: Tue, 10 Jan 2017 23:08:19 +0000
> > Message-ID: <20170110230818.GH30394 at patternsinthevoid.net>
> > To: otf-active at opentechfund.org
> > Cc: Henry de Valence <hdevalence at hdevalence.ca>, isis agora lovecruft <isis at patternsinthevoid.net>
> > Reply-To: isis at patternsinthevoid.net
> > Delivered-To: <isis at patternsinthevoid.net>
> > 
> > The following progress was made in December 2016:
> > 
> >  - Henry and I realised that curve25519's cofactor of 8 causes some
> >    cryptographic problems for the algebraic MACs which we planned to
> >    implement.  The gist of the issue is that the group of points on curve25519
> >    is not actually prime-order, which means that we need some safe way to work
> >    in a prime-order subgroup and to guarantee points to be within said
> >    subgroup.  In retrospect, if we had a time machine, we'd go back a month
> >    ago and use Ed448 instead, since the Decaf point (de-)compression [0]
> >    scheme allows one to neatly map to an image of a subgroup which is of prime
> >    order.  We don't really have time to do that right now, so the alternatives
> >    are that we:
> > 
> >     1. Slowly and carefully reason about every curve point and scalar and
> >        whether it need to be multiplied by the cofactor or the inverse of the
> >        cofactor (respectively).  This is the standard solution, but it's not
> >        a generalised solution.
> > 
> >     2. Figure out how to get Decaf working for curve25519.
> > 
> >    We've made some progress on both these fronts, and the security proofs for
> >    the revised protocol.
> > 
> >  - I found a rather nasty bug which appears to exist in nearly every Elligator2
> >    implementation.  I've notified some of the authors of the bug.  Henry and I
> >    are still investigating the severity of it, but it looks pretty bad and we
> >    think that the decoding of a uniform representative is not resulting in a
> >    point on the curve.  If you're using Elligator right now you should
> >    probably come talk to me privately.
> > 
> >  - We've implemented the algebraic MAC scheme defined in [1], but we're not
> >    ready to publicly release it, as we're currently dealing with the cofactor
> >    issues mentioned above, and seeking further review.  Out of anxiety that
> >    other projects would actually use our MAC scheme before we've assembled
> >    some reasoning or proof w.r.t. its security, we're not releasing the code
> >    publicly yet.
> > 
> >  - We've also begun work to construct the anonymous credentials based on the
> >    above algebraic MACs (defined in the same paper), which we're also not
> >    releasing yet, for the same reasons as above, and with the additional
> >    reason that it's not finished yet.
> > 
> > Happy holidays and new year to everyone!
> > 
> > [0]: https://mikehamburg.com/papers/decaf/decaf.pdf
> > [1]: https://eprint.iacr.org/2013/516
> > 
> > Best regards,
> > -- 
> >  ♥Ⓐ isis agora lovecruft
> > _________________________________________________________
> > OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
> > Current Keys: https://fyb.patternsinthevoid.net/isis.txt
> 
> 
> 
> ----- End forwarded message -----
> 
> -- 
>  ♥Ⓐ isis agora lovecruft
> _________________________________________________________
> OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
> Current Keys: https://fyb.patternsinthevoid.net/isis.txt



----- End forwarded message -----

-- 
 ♥Ⓐ 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/d2adbd33/attachment.sig>


More information about the tor-reports mailing list