Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice | Hacker News Reader

Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice

jhalderm.com

69 pointsalanfranzoni34 comments

Strange that they recommend an elliptic-curve based implementation considering it's not quantum resistant.

Universal Quantum computers were barely started to be announced at that time by IBM and Google.

There likely will not be a cryptanalytic capable quantum computer for over a few decades.

I bet that's the NSA's (public) company line

Actually wasn’t the latest gov standard pushing for quantum-resistant algos? I vaguely remember some controversy over it on HN, because the switched recommendation was sudden and came out of nowhere (with at least one suggestion that they must be nearing it, or someone else is). Dont follow this topic normally, which is why I’m so vague on this, and possibly wrong.

If you're talking about NIST, they've initiated the process to standardise post-quantum public key crypto: https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Pos...

Round 1 submissions were received by November 2017: https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...

Decades is way too pessimistic. Remember, tech grows exponentially.

Not a legitimate complain at all--the jury is still out as to whether it will ever be possible to create a quantum computer capable of breaking current asymmetric primitives.

I'm assuming you're referring to the physical difficulties of creating such a device, since the theory has been there for a while now.[1]

I don't know why you're saying this isn't a "legitimate complaint" (or what even gives you the legitimacy to criticize such things), if anything this is just as, if not more legitimate than your comment.

Time and time again people thought we didn't need to worry about bigger registers/more memory/int overflow/screen sizes/etc. and they were proven wrong every time. Given everything we know so far and everything we've achieved in this field, I'd bet my money on the fact that we will have such capable devices in the future.

1. https://en.wikipedia.org/wiki/Shor%27s_algorithm

Wow, people using 512 bit keysizes in 2018??

Back in 2014 I got the recommendation to ditch 2048 in favor of 4096.

This is relevant to my interests. Thank God we're already using ECC for everything.

I'm confused... Wasn't all that published in 2015 already?

Edit: ah it says it right there on this article: The full version of this paper was published in Proceedings of the 22nd Conference on Computer and Communications Security (CCS), October 2015, ACM

Mods, maybe add a "2015" to the title?

Added, thanks.

Un-added, since we've changed the URL to an updated version of the paper.

Working link http://sci-hub.se/downloads/17ae/10.1145@3292035.pdf

https://weakdh.org/imperfect-forward-secrecy.pdf

Changed from https://sci-hub.tw/10.1145/3292035. Thanks!

There's an updated version of the paper that was published today, so here's an even better link: https://jhalderm.com/pub/papers/weakdh-cacm19.pdf

Source: I'm an author.

Thanks! Changed from https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf.

https://dl.acm.org/citation.cfm?doid=2810103.2813707

It's open access, should change to this link

localhost? wrong redirect?

It's a sci-hub link; does your network hijack DNS to block it?

I'm also receiving a locahost redirect over Verizon Wireless in the US when using Chrome for iOS.

DNS resolves to 80.82.77.83 and .84. When I surf directly to that IP I am redirected to https://sci-hub.se which seems to load correctly. That implies this is the correct server and not a MITM.

When using CloudFlare's DNS VPN I get the same IPs, so this is not a VZW injected IP.

It seems the Sci Hub site itself is doing the local host redirect...?

Working link: http://sci-hub.se/downloads/17ae/10.1145@3292035.pdf

So that thing I learned last semester is useless?

Use the elliptic curve version instead https://security.stackexchange.com/questions/46802/what-is-t...

This is built into modern browsers so you can use that as the basis for HMAC if you can't trust TLS or have something like an open URL for a lambda function that in theory should only be hit by someone's webhook (ie. Slack)

You should have learned this paper last semester, as the paper is from 2015 and is relevant if you study DH.

Anyway, for an application developer (as opposed to a crypto engineer), just use libsodium when you control both sides.

If you need to interop with someone else, use TLS 1.3 if you can, or TLS 1.2 but only with ciphers that support PFS and AEAD, i.e. in practice x25519 and P-256 ECDHE with RSA signatures with AES GCM or ChaCha20Poly1305.

Same primitives are available in SSH.

If you can, don't use IPSec, use wireguard.

Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you.

> Don't use pgp/openpgp/gpg email, use signal. You can use gpg to sign packages and encrypt backups, but the email integration and UX will kill you.

Is there any problem with the crypto that gpg uses, or is it just a matter of the UX?

Gpg can use a lot of different crypto primitives. Some do have problems, some are kinda broken but still good enough for use, some are too easy to make mistakes so gpg is probably bugged, and some are top of the line.

Gpg email also leak some more metadata than signal does. But it leaks to different parties, so this is not clear-cut.

You can configure it to use crypto that is ok (and then use it to sign software packages or encrypt backups, like I wrote above, especially when interaction with gpg is done by scripts, not manually by humans, and key distribution is out of band and PFS is not needed).

For back and forth messages between two or more people, lack of forward secrecy is a problem, integration with the email program is a problem, email metadata is a problem (not just to and from but also the subject line), teaching your confederates to not reply in the clear quoting the entire decrypted message you sent is a problem, etc.

Security practitioners basically believe email cannot be saved, it cannot be used securely by regular people and its only use is to bootstrap something else.

> not just to and from but also the subject line

Subject is hidden in newer software e.g. Enigmail and K9 (it's moved to encrypted part and replaced with a placeholder see https://github.com/autocrypt/memoryhole).

Is libsodium the de facto standard instead of the original NaCl?

If so, what are the reasons? Just enhanced usability, since I recall libsodium using the NaCl crypto primitives almost directly as-is?

From the readme:

> It is a portable, cross-compilable, installable, packageable fork of NaCl, with a compatible API, and an extended API to improve usability even further.

> Sodium supports a variety of compilers and operating systems, including Windows (with MingW or Visual Studio, x86 and x64), iOS, Android, as well as Javascript and Webassembly.

Look at the release notes on the releases page to see what kind of things they do.

https://github.com/jedisct1/libsodium/releases

Reply on news.ycombinator.com