-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
since enable-ec_nistp_64_gcc_128 is disabled by default on OpenBSD due to compiler bugs [1] I wanted to ask how bad is it (in relay context) to ignore the usual tor log entry:
We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
Tor's changelog "highly recommends" it [2].
Can this be "translated" to something like
"the relay's bandwidth usage and usefulness will be reduced"
"latency will be higher"
"security will be degraded due to fallback to DH-1024" ?
thanks, nusenu
[1] http://article.gmane.org/gmane.os.openbsd.misc/218944 [2] https://gitweb.torproject.org/tor.git/plain/ReleaseNotes?id=tor-0.2.5.10
On Mon, 22 Jun 2015 18:36:19 +0200 nusenu nusenu@openmailbox.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
since enable-ec_nistp_64_gcc_128 is disabled by default on OpenBSD due to compiler bugs [1] I wanted to ask how bad is it (in relay context) to ignore the usual tor log entry:
We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.
Tor's changelog "highly recommends" it [2].
Can this be "translated" to something like
"the relay's bandwidth usage and usefulness will be reduced"
"latency will be higher"
"security will be degraded due to fallback to DH-1024" ?
It's exactly what it says on the tin. Your relay will burn more CPU doing ECDHE as part of TLS, but it will have no security impact unless there is a bug in the non-optimized ECDH code.
"TLS connections will take longer to be established, because the key exchange takes longer, but once connected there is no further impact".
Hi,
Last I heard NIST groups are rubbish. You're better off without them for security. Am I wrong?
--leeroy
On Mon, 22 Jun 2015 15:55:59 -0400 "l.m" ter.one.leeboi@hush.com wrote:
Last I heard NIST groups are rubbish. You're better off without them for security. Am I wrong?
DHE is worse (logjam being a recent high profile example), and is far slower. It's important to remember that TLS being broken while far from ideal is insufficient for adversaries since they will need a Curve25519 break as well to actually get plaintext.
It is worth noting that as of 0.2.7.x, tor will *require* OpenSSL with ECDH support, and one of P-244 or P-256. There is an IETF draft circulating for standardizing other curves (Ed25519, Ed448) which hopefully will see uptake in the longer run, but ECDHE with the NIST curves is the current "least bad" choice.
Regards,
On 22 June 2015 at 14:55, l.m ter.one.leeboi@hush.com wrote:
Hi,
Last I heard NIST groups are rubbish. You're better off without them for security. Am I wrong?
With regards to security, no one[0] who generates curves or implements ECC (as evidenced by the recent CFRG discussions or ECC Conference) seriously believes the NIST curves are backdoored.
They do believe the NIST cruves lack security properties other curves have, are less performant than other curves, and have a sufficiently ambiguous origin to not be desirable. But the last one, the distrust of the curves, and desire for new ones (meaning desire based solely on that point) comes more from national agencies who want to mandate national curves - the Chinese and Russians being good examples.
-tom
[0] +/- a tiny epsilon I'm sure
-
l.m -
nusenu -
Tom Ritter -
Yawning Angel