From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by sourceware.org (Postfix) with ESMTPS id 1E53E3875A22 for ; Mon, 25 Jul 2022 13:46:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1E53E3875A22 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B7FFB611A0 for ; Mon, 25 Jul 2022 13:46:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D2E2DC341C6 for ; Mon, 25 Jul 2022 13:45:59 +0000 (UTC) Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 20799eb9 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO) for ; Mon, 25 Jul 2022 13:45:57 +0000 (UTC) Resent-From: "Jason A. Donenfeld" Resent-Date: Mon, 25 Jul 2022 15:45:56 +0200 Resent-Message-ID: Resent-To: libc-alpha@sourceware.org X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5C797C43334 for ; Mon, 25 Jul 2022 13:26:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235503AbiGYN0M (ORCPT ); Mon, 25 Jul 2022 09:26:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235507AbiGYN0L (ORCPT ); Mon, 25 Jul 2022 09:26:11 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA517614F for ; Mon, 25 Jul 2022 06:26:10 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id b10so10449754pjq.5 for ; Mon, 25 Jul 2022 06:26:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=ub7Jm7xVeiVXdiE/MTDklMnRqIlrehUSb1rrC7mzHfo=; b=Jvoo6bEWwSyFHnvVx+KYhHgGG8WHSWV2gUMUPCOgg7/9b7WRcQw9EeZ0qyQXDh+FAA co3zu+sCFzugYiAfSctYar8GxUFpw81/jm0XVsGGyf6nF0Yo9Jvhud3CD4l3HL7UULb+ WRr9ZNzhPmoWrXP1X+yez0D64jUtLcXUCNAvmzND0rD6D9lC9psRq1EKPuAQggX3Ap60 TpAxHBXDiP2IhXn1ngGkF8mcmhu0x9Isfse4ayOTkVnqx8MufzQUEGkjLBiYPDpXFXPB 1Lg8VCnHWC+jJClZNBILJtWHP/iX5PYIAJTXfWUJe22s9qqRbfefBDN1j5qsXKANz531 awTA== X-Gm-Message-State: AJIora/yQH8lwk6vQlU+PfKTVG+WZUCGyiZpxxubeITIfg3LDYk8bJNP JyB2bnS5eNxoCzp2PLcBrjBRmTlwH2gKHhWlzWJQfmel X-Google-Smtp-Source: AGRyM1tOEXouZdo6YTpIdz/RcZ+HgbGPOBjx0+Gtt9w84buNpYV72y/nZ25YTsi1QRMI1IZjwbH9mog8JbB4y4sLjx4= X-Received: by 2002:a17:90b:4aca:b0:1f0:3395:6432 with SMTP id mh10-20020a17090b4aca00b001f033956432mr31308778pjb.19.1658755570298; Mon, 25 Jul 2022 06:26:10 -0700 (PDT) MIME-Version: 1.0 References: <87bktdsdrk.fsf@oldenburg.str.redhat.com> In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Mon, 25 Jul 2022 09:25:58 -0400 Message-ID: Subject: Re: arc4random - are you sure we want these? To: "Jason A. Donenfeld" Cc: Linux Crypto Mailing List Content-Type: text/plain; charset="UTF-8" Precedence: bulk X-Mailing-List: linux-crypto@vger.kernel.org X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2022 13:46:02 -0000 On Mon, Jul 25, 2022 at 7:08 AM Jason A. Donenfeld wrote: > ... > > The performance numbers suggest that we benefit from buffering in user > > space. > > The question is whether it's safe and advisable to buffer this way in > userspace. Does userspace have the right information now of when to > discard the buffer and get a new one? I suspect it does not. I _think_ the sharp edge on userspace buffering is generator state. Most generator threat models I have seen assume the attacker does not know the generator's state. If buffering occurs in the application, then it may be easier for an attacker to learn of the generator's state. If buffering occurs in the kernel, then generator state should be private from an userspace application's view. Jeff