Opened 8 years ago

Closed 8 years ago

#8014 closed defect (fixed)

Reject the reference-implementation of curve25519 from donna in a more comprehensible way.

Reported by: mr-4 Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version: Tor: 0.2.4.8-alpha
Severity: Keywords: tor-relay
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

during ./configure I get the following result:
[...]
checking whether we can use curve25519-donna-c64... no
checking whether we can use curve25519 from nacl... no

I do have nacl(-devel) installed on my machine. Closer inspection of config.log tells me that conftest.c has "#include <crypto_scalarmult_curve25519.h>". That file is in /usr/include/nacl, so I had to add "-I/usr/include/nacl" for this particular error to pass.

That didn't work though as I am now getting "conftest.c:58:4: error: #error Hey, this is the reference implementation!". The conftest.c file itself has this:

#include <crypto_scalarmult_curve25519.h>
#ifdef crypto_scalarmult_curve25519_ref_BYTES
#error Hey, this is the reference implementation!
#endif

"crypto_scalarmult_curve25519_ref_BYTES" is indeed defined in /usr/include/nacl/crypto_scalarmult_curve25519.h, so how am I supposed to satisfy this test then?

Child Tickets

Change History (6)

comment:1 Changed 8 years ago by rransom

Resolution: invalid
Status: newclosed

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.

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.
  • No one should be distributing packages which claim to be NaCl but have some of the pieces removed -- that's a recipe for confusion. Many of the cryptographic primitive implementations in NaCl (as of the last time I looked at it) do not come with source code; if your OS distribution has a policy against distributing such packages, they shouldn't ship a fake/mutilated NaCl package.

comment:2 in reply to:  1 ; Changed 8 years ago by mr-4

Replying to 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.

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.

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!

  • No one should be distributing packages which claim to be NaCl but have some of the pieces removed -- that's a recipe for confusion. Many of the cryptographic primitive implementations in NaCl (as of the last time I looked at it) do not come with source code; if your OS distribution has a policy against distributing such packages, they shouldn't ship a fake/mutilated NaCl package.

I have no idea whether the nacl package provided with my distro (Fedora) is "mutilated" or not - as far as I could tell, the source rpm consists of ... sources, there aren't any binaries. So I don't know where you've got that idea that my nacl distribution is "mutilated".

comment:3 in reply to:  2 ; Changed 8 years ago by nickm

Keywords: tor-relay added
Milestone: Tor: 0.2.4.x-final
Resolution: invalid
Status: closedreopened
Summary: nacl library not recognised during tor buildReject the reference-implementation of curve25519 from donna in a more comprehensible way.

Replying to mr-4:

Replying to 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.

comment:4 in reply to:  3 Changed 8 years ago by mr-4

Replying to nickm:

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

Erm,. I don't really know what "scratchbox" is - I use mock (chrooted environment with all the necessary packages for the target arch installed), so don't know whether that would work (probably not).

Here is an idea - my guess is that the Nacl build system creates some sort of "profile" on the target CPU, among oher things.

If that is the case, why won't the Nacl devs provide a tool (executable), which is executed on the target system, builds and stores a profile (in a file, for example), which is then taken and used for the Nacl build on the (more powerful/different-arch) build machine?

I do a similar thing here with autoconf when I do builds using pre-defined "guess" files. Could a similar technique, if used, eliminate the need for probing the build machine and poke my cpu characteristics (and probably build a wrong profile)? Just an idea, but the way I see it, poking the build machine and relying on the answers received isn't going to work.

I know for a fact that Fedora is also using mock as a tool to build their vast array of packages, so they are bound to have similar problems when it comes to this library.

comment:5 Changed 8 years ago by mr-4

...forgot to add something which should be fairly obvious: my suggestion above is only if mock (and other similar) build absolutely won't work and there are no other (sensible and easy-to-implement) alternatives.

comment:6 Changed 8 years ago by nickm

Resolution: fixed
Status: reopenedclosed

I just tweakwed the configure message in 10fb3398087133ad to try to avoid the original confusion.

I've opened #8483 for the other issues not about the original report.

Note: See TracTickets for help on using tickets.