On 15.09.2013 15:16, Erwann Abalea wrote: > Ideally, the second patch should integrate the 2048bits parameters inside > the "generated section", and adapt the Perl code accordingly. > That way, a paranoid sysadmin can run this file in his perl interpreter, > and have his own 512/1024/2048 parameters generated by OpenSSL. > You could also decide to remove that possibility once admin-chosen DH > parameters become available.
I'm definitely in favor of the latter (not sure how many people really do know that ssl_engine_dh.c can be executed as a Perl script - and if we hardcode DH parameters, I'd rather go for well-defined ones). > I don't really trust these particular parameters, given the current > context. See Thomas' response in > http://security.stackexchange.com/questions/41941/consequences-of-tampered-etc-ssh-modulifor > arguments. Well, referring to the last paragraph of that posting, the 2048-bit parameter included in the patch right now *is* such a "Nothing up my sleeve number" (in contrast to the parameters in RFC 5114, e.g.). See http://tools.ietf.org/html/draft-ietf-ipsec-skip-04#section-6.4.1. > Maybe you can consider using some speed-optimized versions of those > parameters, with the optional length field added and set to a suitable > value? That's what the "-dsaparam" option for the "openssl dhparam" call > does. Yes, but it's a bit more than just adding the length... :-) [see dsa_gen.c:dsa_builtin_paramgen()] > There's no security problem if you use ephemeral keys. True, as long as SSL_OP_SINGLE_DH_USE is set. Kaspar
