[tor-bugs] #12498 [Tor]: Implement ed25519 identity keys (prop 220)

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue May 26 20:16:20 UTC 2015


#12498: Implement ed25519 identity keys (prop 220)
-------------------------+-------------------------------------------------
     Reporter:  asn      |      Owner:  nickm
         Type:  task     |     Status:  needs_review
     Priority:  major    |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor      |    Version:  Tor: 0.2.7
   Resolution:           |   Keywords:  026-triaged-1, 027-triaged-1-in,
Actual Points:           |  SponsorU
       Points:  large    |  Parent ID:  #15054
-------------------------+-------------------------------------------------

Comment (by nickm):

 Replying to [comment:20 andrea]:
 > Partial code review!
 >
 >
 > cf9d780b570fa3ebf02e555c45f62d8b1bc38bcf:
 >
 >    - tor_cert_sign_impl() leaks memory (encoded is never freed), but
 otherwise
 >      appears correct

 Fixed in 52c4106305d87a9be5e9437c1b529a70b4b82c46

 > 1e3a98f88d5e19239d00356d50f6b598a681d70c:
 >
 >  - As a question of sysadminning the dirauths, one probably wants a way
 >    to keep backups of the keypin journal, and copying it out from under
 >    a running Tor process might lead to a corrupt copy with partially
 >    written lines.  Should we consider making any provision for backups
 >    of the keypin journal without stopping the dirauth's Tor process?

 I thought about this, and the best solution I could come up with was to
 treat unreadable lines as bogus, and to prepend a newline on startup.
 Perhaps we should open a ticket to find a better way?

 > 41cbaf0f267b0d1831aa3cf42e9d279cb171bc6a:
 >
 >  - We're switching microdescriptors in votes over to containing ed25519
 lines
 >    instead of rsa1024 lines if we have a recent enough consensus method;
 are
 >    we sure instead of rather than in addition to is the right choice
 here?

 Pretty sure.  The RSA1024 lines are redundant with the RSA identities in
 the consensus; they are only there now to make sure that two different
 descriptors from different routers will always produce different
 microdescriptors.  (See bug #11743 and commit
 4a621a50f53ebeac62d30f427c2db0c627f80a31 for background.)

 > 72d0d2c9c44cb6df47b35c07f94898f952a52fbc:
 >
 >  - Are we sure checking generated files into the repository like this is
 >    the right thing vs. generating them at build time?

 No, but I think it will be easier to switch post-facto.

 I've gone for the current approach since I want to freeze us to the code
 generated by a particular version of Trunnel with a particular version of
 Tor by default, and because I don't expect every developer to have to
 install trunnel.  But see #16199 and #16202 for an alternative.


 I think that covers all the questions and suggestions from your review so
 far, but please let me know if I missed some?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12498#comment:22>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list