On Mon, Sep 9, 2024 at 3:10 AM Solène Rapenne <sol...@perso.pw> wrote: > hi, I noticed that when using diffie-hellman parameters with smtpd and relayd, > there is no need to create a separate dhparam file. > > Given how long it takes to generate such file with openssl dhparam -out dh.pem > 4096, I can't imagine the ephemeral keys to be generated on the fly. > > how does it work?
Parameters != private key. The parameters are the group and generator to be used in the exchange, which are public values. After the Logjam paper was published, it was understood that (a) products and admins utterly sucked at generating good parameters, (b) this wasn't an area where having lots of variance helped prevent bulk attacks, and so (c) using a small set of well known, vetted parameters was Just Fine. So, libressl just uses one of the RFC 3526 or (for sub-1536bit security) RFC 2409 prime groups with the generator 2 and that's it. Generating a key inside one of those groups is really fast, being mostly "select a random number in this range" and then performing a modular exponentiation to get the public key. > Is "pki fqdn dhe auto" enough to enable PFS in smtpd? Yes, though I have two caveats, one about technology and one about terminology. The technology caveat is that 'classic' Diffie-Hellman, aka Fixed-Field DH, is disfavored by cryptographers. The issue is that the fixed-field of classic prime groups has more 'structure', properties that we have deduced about it, than is necessary for the operations used in FFDH. I'm not a cryptographer but this seems to threaten to provide more 'grip' for potential specific attacks and general weaknesses. This contrasts with the elliptic-curve groups used by ECDH where they are more abstract/pure and don't have the baggage of reflecting the concrete behavior of the FF groups which grew out of how humans described the behavior of objects in the physical world. You've been around and have presumably observed this and have your own reasons for choosing to enable/deploy FFDH; vaya con dios. The terminology caveat is that while "PFS", aka "Perfect Forward Secrecy", was the original jargon for a particular property of protocols like DHE (and ECDHE), the jargon has evolved to avoid the word 'perfect' and just call it Forward Security, at least as applied to TLS cipher suites: the only use of the word 'perfect' in the TLSv1.3 standard is in the title of a reference from 2015; it otherwise just says "forward security". The cryptographic research community has and will continue to evolve its meaning for the term PFS, but calling anything that has actually been built and standardized 'perfect' is just spitting in the face of the forward progress of science. tl;dr, sure, it'll be secure. Philip Guenther
