On Thu, Jun 04, 2015 at 11:29:00PM +0200, Emmanuel Thomé wrote: > On Thu, Jun 04, 2015 at 05:54:51PM +0200, Willy Tarreau wrote: > > I simply used "openssl dhparam <size>" as suggested, and am trusting > > openssl to provide something reasonably safe since this is how every user > > builds their own dhparam when they don't want to use the initial one. > > > > I have no idea how openssl does it internally, I'm not a cryptanalyst, > > just a user and I have to trust openssl not to fail on me. > > openssl dhparam <size> can be assumed to do its job reasonably well. The > only problem is that with the default primes you are in effect a third > party generating the prime, and you cannot provide a certificate that the > prime you've put as default was indeed produced by this mechanism.
Absolutely, that's the limit of this model. But given that oakley was supposedly properly generated and is now considered broken, I guess the situation is not worse. As I said, my take on this one is "I checked that my system looked OK and that I was alone on it, I generated the params and checked in parallel that there was enough entropy available". That's the best I can do. People can of course think I'm lying and I carefully crafted the string. Just like I could imagine that openssl doesn't really do what it claims it does. That's the principle of using libs or software, you have to trust others for things you cannot do yourself. When you know how to do things yourself, you can limit your dependency on others. > > > A paranoid user would believe that it has been generated by > > > (say) NSA, which convinced you to claim that it's random material > > > > Yes but such paranoid users also accuse everyone of much funnier things > > so I don't care much about what they believe. > > Fair enough. I just point you at the relevant information, you're free to > do whichever way seems most appropriate to you. I agree that the paranoid > user would want to generate his own parameters anyway. Yep. > P.S: openssl dhparams takes a while because prime testing is slow. At > least, algorithmically speaking, this is the difficult point. That was my understanding as well, explaining why sometimes it's fast and sometimes very slow. Thanks, Willy
