On Tue, Sep 03, 2013 at 04:53:52PM +0200, Dr. Stephen Henson wrote:
> The SSL_CONF_cmd interface in OpenSSL 1.0.2 and later might be
> useful too. It's designed to provide a common format for configuration.
Thanks, I'll take a look at that when I get a chance. [ I'm still
concerned about the DANE support in 1.0.2 by the way, it should
IMHO be dropped or fixed, neither seems to be happening. ]
> It was documented on my hard disk, I just forgot to push it, oops. It's
> included in commit c3eb33763bf2999843fe4124f3f39dea6edc26e6
Thanks. Any chance that documenting new interfaces will become a
requirement for code contributions to OpenSSL?
> > Should there also be an SSL_CTX_set_dh_auto(ctx, 1)? With suitable
> > compiled-in MODP groups (perhaps from RFC 5114, though there is I
> > think no gain from the DSA-style subgroups in TLS since "q" is not
> > sent to the client).
>
> There is some gain server side during key generation, but nothing client side.
The more important part of the question (than speed-ups, ...) is
whether OpenSSL should use a more complex DH group selection strategy
than just "export" vs "not export"? Namely, should OpenSSL servers
choose DH parameters with strength commensurate to the symmetric
key size? What would be the performance implications (would this
require DSA-style groups to be practical or is that still too costly
with larger primes). Should the GnuTLS developers be left to solve
the mess they've created, or is it time to consider moving in the
direction they've all-too-boldly embarked upon?
To the specific point in your reply, does OpenSSL actually support
DSA-style groups (with p, g and q) where DH groups are expected?
For example can such groups be returned from the temp DH callback?
Certainly the dhparam(1) command does not seem to support groups
with "q" values.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
