
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice - alanfranzoni
https://jhalderm.com/pub/papers/weakdh-cacm19.pdf
======
samirm
Strange that they recommend an elliptic-curve based implementation considering
it's not quantum resistant.

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

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

~~~
setr
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.

~~~
tkhoven
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...](https://csrc.nist.gov/Projects/Post-Quantum-
Cryptography/Post-Quantum-Cryptography-Standardization)

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

------
lerno
Wow, people using 512 bit keysizes in 2018??

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

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

------
gregschlom
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?

~~~
tlb
Added, thanks.

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

------
dweekly
Working link [http://sci-
hub.se/downloads/17ae/10.1145@3292035.pdf](http://sci-
hub.se/downloads/17ae/10.1145@3292035.pdf)

------
dadrian
[https://weakdh.org/imperfect-forward-
secrecy.pdf](https://weakdh.org/imperfect-forward-secrecy.pdf)

~~~
dang
Changed from [https://sci-hub.tw/10.1145/3292035](https://sci-
hub.tw/10.1145/3292035). Thanks!

~~~
dadrian
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](https://jhalderm.com/pub/papers/weakdh-cacm19.pdf)

Source: I'm an author.

~~~
dang
Thanks! Changed from [https://weakdh.org/imperfect-forward-secrecy-
ccs15.pdf](https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf).

------
tosh
[https://dl.acm.org/citation.cfm?doid=2810103.2813707](https://dl.acm.org/citation.cfm?doid=2810103.2813707)

~~~
kardos
It's open access, should change to this link

------
pfortuny
localhost? wrong redirect?

~~~
dweekly
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](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...?

~~~
dweekly
Working link: [http://sci-
hub.se/downloads/17ae/10.1145@3292035.pdf](http://sci-
hub.se/downloads/17ae/10.1145@3292035.pdf)

------
antoineMoPa
So that thing I learned last semester is useless?

~~~
wolf550e
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.

~~~
jolmg
> 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?

~~~
wolf550e
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.

~~~
Boulth
> 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](https://github.com/autocrypt/memoryhole)).

