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]
Date:   Fri, 07 Jan 2022 07:37:30 +0100
From:   Nicolai Stange <nstange@...e.de>
To:     Herbert Xu <herbert@...dor.apana.org.au>
Cc:     Stephan Mueller <smueller@...onox.de>,
        Nicolai Stange <nstange@...e.de>,
        "David S. Miller" <davem@...emloft.net>,
        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, simo@...hat.com
Subject: Re: [PATCH v2 03/18] crypto: dh - optimize domain parameter serialization for well-known groups

Herbert Xu <herbert@...dor.apana.org.au> writes:

> On Thu, Jan 06, 2022 at 03:30:04PM +0100, Stephan Mueller wrote:
>>
>> This means in FIPS mode, invoking the algo of "dh" should not be possible. 
>> Yet, on the other hand, we cannot mark "dh" as fips_allowed == 0 as the 
>> templates would not be able to instantiate them.
>
> Right, we have exactly the same problem with sha1 where sha1
> per se should be not be allowed in FIPS mode but hmac(sha1)
> should be.
>
>> Therefore, I think we should mark "dh" as CRYPTO_ALG_INTERNAL if in FIPS mode. 
> I think the annotation should be added to testmgr.c.  We could
> mark dh and sha1 as not fips_allowed but allowed as the parameter
> of a template.  This could then be represented in the crypto_alg
> object by a new flag.
>
> This flag could then be set automatically in crypto_grab_* to
> allow them to be picked up automatically for templates.
>
> I'm already writing this up for sha1 anyway so let me polish it
> off and I'll post it soon which you can then reuse it for dh.

Perfect, this will solve my problem with how to handle "dh"
vs. fips_enabled quite nicely.

Many thanks!

Nicolai

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ