[exim-dev] [Bug 2095] custom dhparams with 2236 bit fail to …

Top Page
Delete this message
Reply to this message
Author: admin
Date:  
To: exim-dev
Old-Topics: [exim-dev] [Bug 2095] New: custom dhparams with 2236 bit fail to load with default tls_dh_max_bits (openssl)
Subject: [exim-dev] [Bug 2095] custom dhparams with 2236 bit fail to load with default tls_dh_max_bits (openssl)
https://bugs.exim.org/show_bug.cgi?id=2095

Phil Pennock <pdp@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |pdp@???
           Assignee|jgh146exb@???       |pdp@???


--- Comment #4 from Phil Pennock <pdp@???> ---
No, looks like it's the API limitation: it's 2236 but OpenSSL tells us 2240
because OpenSSL just tells us how many _octets_ are used, not how many bits.

When the code was written, I was dealing with the GnuTLS rewrite and their
overshooting (2237/2238 bits) the Debian problems, so I mostly paid attention
to that.

Frankly, if OpenSSL can't tell us the size, I don't care enough. If
compatibility with old NSS isn't an issue and someone wants to push to the
limit, let them raise the knob, that's why I _added_ a knob instead of just
hard-coded size limits: those who want to play and trade off compatibility can
do so.

I'm going to add compatibility for the OpenSSL 1.1 API to get the accurate
size, and people using older libraries can just be SOL: you can't credibly be
demanding the very best crypto and protection while using old libraries. We
should reward people who're up-to-date, not add even more corner cases to
what's already a hairy concept to explain, to handle old libraries.

--
You are receiving this mail because:
You are on the CC list for the bug.