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

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?

Trac:
Username: mr-4

changed milestone to %Tor: 0.2.4.x-final

added component::core tor/tor milestone::Tor: 0.2.4.x-final priority::medium reporter::mr-4 resolution::fixed status::closed tor-relay type::defect version::tor 0.2.4.8-alpha labels

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.

Trac:
Resolution: N/A to invalid
Status: new to closed

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".

Trac:
Username: mr-4

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.

Trac:
Summary: nacl library not recognised during tor build to Reject the reference-implementation of curve25519 from donna in a more comprehensible way.
Keywords: N/A deleted, tor-relay added
Milestone: N/A to Tor: 0.2.4.x-final
Resolution: invalid to N/A
Status: closed to reopened

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.

Trac:
Username: 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.

Trac:
Username: mr-4

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

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

Trac:
Resolution: N/A to fixed
Status: reopened to closed

closed

mentioned in issue #8483 (moved)

moved to tpo/core/tor#8014 (closed)

mentioned in issue tpo/core/tor#8483 (closed)