From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 0DC9C3858C53 for ; Mon, 4 Apr 2022 15:00:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0DC9C3858C53 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-191-TeL8yBu6PBqhg-giARTIUA-1; Mon, 04 Apr 2022 11:00:37 -0400 X-MC-Unique: TeL8yBu6PBqhg-giARTIUA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E8C06811E9B; Mon, 4 Apr 2022 15:00:36 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1CD3FC27E8C; Mon, 4 Apr 2022 15:00:35 +0000 (UTC) From: Florian Weimer To: "Jason A. Donenfeld via Libc-alpha" Cc: "Jason A. Donenfeld" Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function References: <20220328220936.2724834-1-goldstein.w.n@gmail.com> <7b48ece6-392a-0850-c136-01ab751273ef@linaro.org> <72332228-093c-5186-789f-8616cfb93793@linaro.org> <87h7786gwy.fsf@oldenburg.str.redhat.com> Date: Mon, 04 Apr 2022 17:00:31 +0200 In-Reply-To: (Jason A. Donenfeld via Libc-alpha's message of "Mon, 4 Apr 2022 16:54:12 +0200") Message-ID: <87a6d06ghc.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 15:00:42 -0000 * Jason A. Donenfeld via Libc-alpha: > _However_, based on what people have said in this thread, this all > seems highly unnecessary, since you just need some boring > statistically uniform randomness without any crypto or security > requirements of any kind, and it simply needs to be fast and dumb. If > that's the wrong set of requirements for this problem (I still have no > idea what the bigger picture here is), please pipe up. If we can make a cryptographically secure generator fast enough, it would relieve programmers of the need to choose between that and another generator that just gives some random-looking bits fast. If programmers don't have to make a choice, they can't choose incorrectly (introducing performance bugs or security bugs). For example, the system call overhead could be prohibitive for things like hash map keys if these hash maps are not used much before they are discarded again. Thanks, Florian