[PATCH 2/2] virnettlscontext: Don't pass static key length to gnutls_dh_params_generate2()

Martin Kletzander mkletzan at redhat.com
Wed Dec 22 14:38:14 UTC 2021


On Wed, Dec 22, 2021 at 02:12:37PM +0100, Ján Tomko wrote:
>On a Tuesday in 2021, Michal Privoznik wrote:
>>As encryption norms get more strict it's easy to fall on the
>>insecure side. For instance, so far we are generating 2048 bits
>>long prime for Diffie-Hellman keys. Some systems consider this
>>not long enough. While we may just keep increasing the value
>>passed to the corresponding gnutls_* function, that is not well
>>maintainable. Instead, we may do what's recommended in the
>
>Is there a promise gnutls will increase those in the future?
>

That is the whole point of the levels that they are not fixed and also
that distributions can select theirs.  And the fact that you can have
one option for the whole system.  Which makes me realise that we should
actually try that and not pick a level ourselves.  Having said that I
should also add that I do not know how to do that.  Maybe use "SYSTEM"
or "DEFAULT"?

>>gnutls_* manpage. From gnutls_dh_params_generate2(3):
>>
>>  It is recommended not to set the number of bits directly, but
>>  use gnutls_sec_param_to_pk_bits() instead.
>>
>>Looking into the gnutls_sec_param_to_pk_bits() then [1], 2048
>>bits corresponds to parameter MEDIUM. Therefore, we want to chose
>>the next size (HIGH) to be future proof.
>
>IMO this patch should use MEDIUM and the bump should be separate.
>
>>
>>1: https://www.gnutls.org/manual/gnutls.html#tab_003akey_002dsizes
>>
>>Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>---
>> src/rpc/virnettlscontext.c | 13 ++++++++++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>
>
>Reviewed-by: Ján Tomko <jtomko at redhat.com>
>
>Jano


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20211222/e42c4c17/attachment-0001.sig>


More information about the libvir-list mailing list