How bad is not having 'enable-ec_nistp_64_gcc_128' really? (OpenBSD)
-----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 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViDmDAAoJEFv7XvVCELh0Fi0QAKF0/7eVWgL5gExyGcCugz66 9CJOaNGVdeqb8LDxH/KEW4xC+MLhqMQ/+dL7iVOZIOtCM6i4vTpD3u4ZVnFhcGfx luyX78TqXDW3riV3izBWYScYxQdeHGv3XFXQlbGi7WQYfRt0AdorchmP2xuxD7Cg zGZFk4Bggj3qnW1sd/G3JvJL0bUi7iBKrQwPTDlnK3YSGbTYpU6lS3dQqbHqNYin yrwtlNSCi9DFjbQm5g4yjvaawnmOuxf8dlm54Ltjdn2cIHsXaPqQ6kXICiukrJhE ZLfTnPBd3yngyoq9xe7bW9P4mNVkTNmAU3VqGgEq1gSUJQObXkzOKAz63z9WAqQl GBvZFtwkbdBM4pjfWaG5FjDRc+awXxP/8K/d2vF2r6KAwkbh9Fw2uhjC6yu5c6hB KtQaovd+we+Ag4vDdE6lbQPLiCbPBiFdB6qYjkWbVflYcrsYQPoCgwjaodbV7I/Y 8Kb3Lx2C8+HFLtktEh19tOk34iKVliQk7FjE2FoiKkWryRYtY5KUAfFS8hOCfBqr 2XYtWGqQ9eh14RqvBu7CuN1cKCc0EQLcr6BF9uvd6EYtKZsa5rQC+y9Bbbd65MwB qU7lLckEkG+qwzgvuyOBvGwN8JmMmTBQASsdalAUscQFbPq7wySp9tz21pu8mOje NRRdnL1/3X9KcCMLMCVk =Oa2Z -----END PGP SIGNATURE-----
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". -- Yawning Angel
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, -- Yawning Angel
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
participants (4)
-
l.m -
nusenu -
Tom Ritter -
Yawning Angel