[tor-bugs] #8014 [Tor]: Reject the reference-implementation of curve25519 from donna in a more comprehensible way. (was: nacl library not recognised during tor build)

[Tor Bug Tracker & Wiki]

#8014: Reject the reference-implementation of curve25519 from donna in a more
comprehensible way.
-----------------------+----------------------------------------------------
    Reporter:  mr-4    |       Owner:                    
        Type:  defect  |      Status:  reopened          
    Priority:  normal  |   Milestone:  Tor: 0.2.4.x-final
   Component:  Tor     |     Version:  Tor: 0.2.4.8-alpha
  Resolution:          |    Keywords:  tor-relay         
      Parent:          |      Points:                    
Actualpoints:          |  
-----------------------+----------------------------------------------------
Changes (by nickm):

  * keywords:  => tor-relay
  * status:  closed => reopened
  * milestone:  => Tor: 0.2.4.x-final
  * resolution:  invalid =>


Comment:

 Replying to [comment:2 mr-4]:
 > Replying to [comment:1 rransom]:
 > > The Curve25519 implementations included with Tor are considerably
 faster than the reference implementation in NaCl.  Do not try to force Tor
 to link to a copy of NaCl whose build process chose the reference
 implementation of Curve25519.
 > I am not trying to "force" anything - I simply wanted to take advantage
 of nacl and wasn't aware that such implementation is included with tor.
 >
 > Perhaps the next time you guys type in your changelogs you should point
 this out and make it clear that nacl implementation *is* included with tor
 so that I (and others) won't try to make wild guesses.

 The changelog said:
 {{{
       Tor can use one of two built-in
       pure-C curve25519-donna implementations by Adam Langley, or it
       can link against the "nacl" library for a tuned version if present.
 }}}

 I meant this to communicate that there are two built-in versions, and that
 the nacl version is optional.  Sorry it wasn't clear enough.

 > > Also:
 > >  * No one should be distributing binary packages of NaCl.  NaCl's
 build process chooses the fastest implementation of a cryptographic
 primitive which works on the processor and OS on which it was built; it
 can quite easily choose one that won't work or has poor performance on a
 different box.

 Well, that's not *quite* true.  I just talked to DJB (he's sitting 2
 meters away from me right now), and he says that binary packages of nacl
 are tricky and potentially suboptimal, not forbidden.

 > So, cross-compilation is out of the question then, even if it is done in
 chrooted environment (which 99% of all automated cross-compilation builds
 are)? Very wise indeed (not!). Whoever bright spark decided upon that
 deserves to be shot!

 If you want to cross-compile nacl, the recommended solution is to use
 scratchbox.  (Says DJB.)



 The underlying issue here seems to be that when nacl is using its
 reference implementation, we just say "no" rather than producing a more
 useful "nacl is here but it wasn't actually built with a curve25519
 implementation we like" message.  I think that ought to get fixed; it's
 unintuitive why the library would be present but unusable.

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