linux-kernel - Re: [PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <878rwvegz1.fsf@suse.de>
Date:   Wed, 08 Dec 2021 07:41:22 +0100
From:   Nicolai Stange <nstange@...e.de>
To:     Stephan Müller <smueller@...onox.de>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Nicolai Stange <nstange@...e.de>,
        Hannes Reinecke <hare@...e.de>, Torsten Duwe <duwe@...e.de>,
        Zaibo Xu <xuzaibo@...wei.com>,
        Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
        David Howells <dhowells@...hat.com>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
        qat-linux@...el.com, keyrings@...r.kernel.org
Subject: Re: [PATCH 16/18] crypto: dh - calculate Q from P for the full public key verification

Stephan Müller <smueller@...onox.de> writes:

> Am Mittwoch, 1. Dezember 2021, 01:48:56 CET schrieb Nicolai Stange:
>
>> As the ->q in struct dh_ctx gets never set anywhere, the code
>> in dh_is_pubkey_valid() for doing the full public key validation in
>> accordance to SP800-56Arev3 is effectively dead.
>> 
>> However, for safe-prime groups, Q = (P - 1)/2 by definition and this
>> enables dh_is_pubkey_valid() to calculate Q on the fly for these groups.
>> Implement this.
>> 
>> With this change, the last code accessing struct dh_ctx's ->q is now gone.
>> Remove this member from struct dh_ctx.
>
> Isn't it expensive to always calculate Q for a-priori known values? Why not 
> add Q to the safe-prime definitions and do not do this operation here?

I actually considered this when writing the patch: it's basically a
time-memory tradeoff and I opted for time here. The reason is that I'd
expect the rather trivial Q calculation to be negligible when compared
to the subsequent mpi_powm() operation in dh_is_pubkey_valid(). OTOH, as
the size of Q is (almost) equal to that of P, the space needed for
storing all the the individual groups' precomputed Qs would be
significant. So I'd say let's wait and see whether the dynamic Q
calculation does actually show up in profiles before thinking about
optimizations like e.g. precomputations.

Thanks,

Nicolai

>
> If you need Q for all of those safe-primes, you may get them from [1] and 
> following lines.
>
> [1] https://github.com/smuellerDD/acvpparser/blob/master/parser/
> safeprimes.h#L346
>
> Ciao
> Stephan
>
>

-- 
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Ivo Totev