Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp3459792ybx; Fri, 8 Nov 2019 21:10:50 -0800 (PST) X-Google-Smtp-Source: APXvYqy6HxiA4btyyckIVjZs5+3WScDqXauW8yZuTuF0r/Jr2ufAkydgpcPLQ+1zg5eDveqcpPQ4 X-Received: by 2002:aa7:db09:: with SMTP id t9mr14685602eds.171.1573276250638; Fri, 08 Nov 2019 21:10:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573276250; cv=none; d=google.com; s=arc-20160816; b=aJJi5596SO98VMKZsopOHXOLisk4i2iTuFXzOZZg/oodPgV5CgsOq3u3YutF4KEx7O 1q3BypXavHr0m/JL8lQI5aHKGOA4a3SyRXOcp7WeI32KknUUyBLcD8JMzbh7o1RMWVHP nAlzojA962cekSxV/xgwc2pHBD0Q5NA2t/V8HgRMAlQgKVTzdSGVvmPfWJsDpRla/r2z hMAJa/8TyBilAXG/kwQVYGgZQqUWEfTi51gRuP+5agnZfggjfYZmUHOiN9MoAtsUdTYo QQ2yt01HaRvrdtEup0EphEd1Tlvfg/gZGFyrBqXnKNOgmpv30XtHWtA1YnhV7AJgOrdM G3ew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7r9ZBGXV/7RhtrsMZpVh5M50eb6appvkBOnLGzJjXKM=; b=vAWj8n4bz8kdgN1Fk1dMPpcSeahR4TM1TuZ1ApWesrFa3w9K1Im7Df95IDMpK8GGgB TOCQd7s5FU6F8ttFyT9G2bo5cf2wEFGeKpVe1HsAvWpb2oLxqanZlv5aqlU5mJFx2LN6 dtMtKb8J1djkRm/api3KF17Zy7heLK81usdOw9RFhXnNJuAbYYaR0DBObJQ5orbJ0omY j3qTmTkxVWZR4u8e248bUkFxbjL2HFZDFxBfi/wyxBSXTeIzsxFQpKblZeLdkYd9Q316 MNbUGY4rep33S8XnYPaLb8KNn9ttsEziPAQESwlF9rlzktsO9U2SjVNY6uJHxVVG5rFh J2PQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h18si5701239edh.352.2019.11.08.21.10.25; Fri, 08 Nov 2019 21:10:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726204AbfKIFD5 (ORCPT + 99 others); Sat, 9 Nov 2019 00:03:57 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:39805 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725788AbfKIFD5 (ORCPT ); Sat, 9 Nov 2019 00:03:57 -0500 Received: from callcc.thunk.org (96-72-102-169-static.hfc.comcastbusiness.net [96.72.102.169] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xA953rLL018550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 9 Nov 2019 00:03:54 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 20A1B4202FD; Sat, 9 Nov 2019 00:03:53 -0500 (EST) Date: Sat, 9 Nov 2019 00:03:53 -0500 From: "Theodore Y. Ts'o" To: Frederick Gotham Cc: linux-crypto@vger.kernel.org Subject: Re: Remove PRNG from Linux Kernel Message-ID: <20191109050353.GD23325@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Fri, Nov 08, 2019 at 03:48:02PM -0000, Frederick Gotham wrote: > > There cannot be any software-based psuedo-random number generators on my > device, and so far I've removed three of them: > > (1) The built-in PRNG inside OpenSSL > (2) The Intel RDRAND engine inside OpenSSL > (3) The simulator library that goes with the tpm2tss engine for OpenSSL > (tcti-mssim) Why must there not be a "pseudo-random number generator"? Who made that rule? What is the goal of not allowing such a thing? Note that in general, most people would not refer to such things as a "PRNG", but a Cryptographic Random Number Generator (CRNG). And in general, it's considered a very good thing put a CRNG in front of a hardware random number generator for several reasons: (1) Hardware random number generators, including TPM-based RNG's are slow, and (2) using a hardware RNG directly means you are investing all of your trust in the hardware RNG --- and hardware RNG have been known to have their share of insecurities. What makes you so sure that the you can trust the implementation of the TPM's random number generator? Far better is to mix multiple entropy sources together, so that if one happens to be insecure, or has failed in some way, you still will have protection from the other entropy sources. > I need to remove the PRNG from the Linux kernel and replace it with something > that interfaces directly with the TPM2 chip. > > Has this been done before? As far as I know, no, because most people would consider this a Really, REALLY, **REALLY** bad idea. Note that the TPM2 chip has a very slow connection to the main CPU, and there are many applications which will need session keys at a high rate (for example, opening multiple https connections when browsing a web page), for which the TPM2 would be totally unsuited. If you really want to use the TPM2 chip, there are userspace libraries which will access it directly, and you can see how slow and painful using the TPM chip really would be.... - Ted