Re: [tor-bugs] #22006 [Core Tor/Tor]: prop224: Validate ed25519 pubkeys to remove torsion component

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#22006: prop224: Validate ed25519 pubkeys to remove torsion component
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, prop224, ed25519, review-    |  Actual Points:
  group-18                                       |
Parent ID:  #21888                               |         Points:
 Reviewer:  nickm                                |        Sponsor:
                                                 |  SponsorR-can
-------------------------------------------------+-------------------------

Comment (by isis):

 Replying to [comment:15 arma]:
 > Replying to [comment:14 nickm]:
 > > I don't think we can do decaf encoding on ed25519 identities: they are
 already published in descriptors and interpreted widely. For hidden
 services and decaf, I don't know how hard the transition would be. The
 only place to change the encoding would be in .onion addresses, and I
 don't know whether there's time/energy to do that in the current state of
 prop224.
 >
 > Happy to be overruled here, but, does this imply that we should stick to
 the current encoding for onion addresses, since if we have to maintain two
 different encodings forever, and other people building Tors will forever
 need to build both kinds, that will make everybody sad?

 Right. I was mostly just writing it down out of hopefulness, and for
 posterity's sake, so that when the current really slow thing really does
 become way too slow, we can revisit the point compression formats and
 speed it up by ~15x. It would be a breaking change, and I'd suggest there
 be an actual proposal for the improvement. (Also, I've been in discussions
 with Mike Hamburg to standardise "Decaf for 25519" a.k.a. "Ristretto", and
 I hear Trevor Perrin is doing some work to standardise "Schnorr-like
 signatures for Decaf" a.k.a. "Schnorrcaf". It would be wise to hold off
 the proposal until the standards are finalised. :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22006#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs