[tor-dev] curve25519_donna vs. crypto_scalarmult_curve25519?

Yawning Angel yawning at schwanenlied.me
Wed Aug 5 05:22:37 UTC 2015


On Tue, 4 Aug 2015 17:55:51 -0400 (EDT)
"Steve Snyder" <swsnyder at snydernet.net> wrote:

> Given a contemporary release of Tor with a contemporary version of
> OpenSSL, under what circumstances is the intrinsic curve25519_donna()
> preferred over the libsodium/NaCl crypto_scalarmult_curve25519(), or
> vice versa?

A quick peek at the libsodium code reveals that it uses curve25519-donna
(64 bit targets), and ref10 (32 bit targets?).

Standard Tor uses curve25519-donna for both. I *think* donna's 32 bit
code should out perform ref10, so libsodium is pointless.

djb's NaCl might have assembly versions that are faster, but the
difference doesn't look massive.

http://bench.cr.yp.to/impl-scalarmult/curve25519.html

> Does it come down to 32-bit vs. 64-bit?  Or CPU instruction sets
> detected at build time?
> 
> Or has libsodium/NaCl been deprecated altogether and just not removed
> from the configure script?

I think mostly this, at this point. Deprecating it might make sense,
since libsodium is basically never going to outperform donna, and it's
not practical to use libsodium/NaCl for Ed25519 due to Tor specific
changes that would be required.

> I'm trying to determine if installation of libsodium in a Tor build
> environment will yield a "better" Tor binary.

If libsodium, then no. If djb's NaCl then *maybe*, but the difference
in practice will probably be fairly negligible (NB: discussing 64 bit
platforms. 32 bit platform performance is somewhat non-interesting to
me, so I haven't measured things in depth).

I'm planning on revisiting this issue at some point, but last I looked
into it, using an assembly optimized Curve25519 implementation was
potentially a 7-10% gain (but is neither from libsodium nor djb NaCl).

https://trac.torproject.org/projects/tor/ticket/8897

-- 
Yawning Angel

ps: 0.2.7.2-alpha and later already does ntor ~25% faster, due to a
faster basepoint multiply being used in the key generation step.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150805/c9373c64/attachment.sig>


More information about the tor-dev mailing list