From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by sourceware.org (Postfix) with ESMTPS id C0C023858C53 for ; Mon, 4 Apr 2022 16:51:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0C023858C53 Received: by mail-yb1-xb31.google.com with SMTP id g9so18754117ybf.1 for ; Mon, 04 Apr 2022 09:51:52 -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:from:date :message-id:subject:to:cc; bh=THFtx5oSLhUF+i1ySUy941V8/eJQMwyIg1HCmAZIivk=; b=mClrYLClx0W8nISGvP+Pn0ReZSXuGzd8SD054aiDYIQW4fSIQr6xOzAis4FFbqydxd AfqUQXMR90e92d9X6gGB7EP70W5Gkfg8ci1JDwDY46/RpfWXjhXOzq5VwxVIyjndn7Vm dY3JZEy4j4LscP7DPEqvveOfW7wVvP7cQwgTqN6VvM0tAoP/ZdhikrnpBrZiHGnRkruq LbWZNuQ1iSNPmwwh2gbaaeUrKRp/dSQiyDr3B2Hg6r6qLXtlaI2uhM7uha33Ej2/77K7 UfGFJ9xn5hrSd5xCiMJMc8ktEmM886vfjjg+ObKg513FcY/pDk0+mE/ILHuFX4hdyS3/ iQng== X-Gm-Message-State: AOAM533VtWwe0MTsVPWZ6vQ1LHeH+MsH7eFoEaXHZSuwNWsTMuMmWmmt pERWJV5Xv/LtLEOPCe1eDMwhWm7E3l4hb60t5YI= X-Google-Smtp-Source: ABdhPJy9i+8gBuMjBzjhEniLF2+SPvKuAcXxJQMG33dWsCiq7ajVTIjmg4plTP98nKT5hokiv7nqsiRpVe51OJhDTNs= X-Received: by 2002:a5b:f83:0:b0:63d:a251:2c51 with SMTP id q3-20020a5b0f83000000b0063da2512c51mr642683ybh.594.1649091112226; Mon, 04 Apr 2022 09:51:52 -0700 (PDT) MIME-Version: 1.0 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> <87a6d06ghc.fsf@oldenburg.str.redhat.com> In-Reply-To: <87a6d06ghc.fsf@oldenburg.str.redhat.com> From: Noah Goldstein Date: Mon, 4 Apr 2022 11:51:41 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function To: Florian Weimer Cc: "Jason A. Donenfeld via Libc-alpha" , "Jason A. Donenfeld" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 16:51:54 -0000 On Mon, Apr 4, 2022 at 10:00 AM Florian Weimer via Libc-alpha wrote: > > * 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). It sounds like you're talking about creating a user facing API. Since random_bits is internal do we really need so much ease of use at the cost of performance? > > 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 >