linux-kernel - Re: [PATCH] KEYS: asym_tpm: Switch to get_random

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: <20191014191150.GB15552@linux.intel.com>
Date:   Mon, 14 Oct 2019 22:11:50 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Pascal Van Leeuwen <pvanleeuwen@...imatrix.com>
Cc:     Ken Goldman <kgold@...ux.ibm.com>,
        "Safford, David (GE Global Research, US)" <david.safford@...com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "open list:ASYMMETRIC KEYS" <keyrings@...r.kernel.org>,
        "open list:CRYPTO API" <linux-crypto@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] KEYS: asym_tpm: Switch to get_random_bytes()

On Wed, Oct 09, 2019 at 08:09:29AM +0000, Pascal Van Leeuwen wrote:
> There's certification and certification. Not all certificates are
> created equally. But if it matches your specific requirements, why not.
> There's a _lot_ of HW out there that's not x86 though ...
> 
> And: is RDRAND certified for _all_ x86 processors? Or just Intel?
> Or perhaps even only _specific (server) models_ of CPU's?
> I also know for a fact that some older AMD processors had a broken
> RDRAND implementation ...
> 
> So the choice really should be up to the application or user.

I'm not seriously suggesting to move rdrand here. I'm trying find the
logic how to move forward with trusted keys with multiple backends (not
only TPM).

AKA we have a kernel rng in existence but no clear policy when it should
be used and when not. This leads to throwing a dice with the design
choices. Even it TPM RNG is the right choice in tpm_asym.c, the choice
was not based on anything (otherwise it would have been documented).

/Jarkko