From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) by sourceware.org (Postfix) with ESMTPS id 0F8213858C53 for ; Mon, 4 Apr 2022 17:22:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0F8213858C53 Received: by mail-ot1-x32a.google.com with SMTP id 88-20020a9d0ee1000000b005d0ae4e126fso5694508otj.5 for ; Mon, 04 Apr 2022 10:22:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=8zF4yEevSm5dWD2fY2xUfFA4THpyX2QTKRzhCs2OenE=; b=bpgRTE7j023l/RIl5VFrE1nvX51zzJoPJ4tB8zB7lCkFc5Xw3biV9lJfml12novGci B1vjy3d9Lsb3Gt9O6Xr+qWMYhjXc/U4HYTo3FRCMhlGHt5ROkoReqMZ0COo13EHR+uEi O2sapp8Ri3rBcroL33kV4FUG2c9yJ1KiWqxjHLD5RpET+idUFojUf7zD43u1+UkkZFKN gqESv4/VA6F3ytjR4LXy113Suu6r8eYWgB/bq1ctjI9cLGi7M7qIvTG57o2JyGpRfJ+8 5bu1EK53uJSPc/s8mYd+NNTSu8Ixya57RN3//3eh798bpaw85ATiRCfhOrJRgm1w8JP0 9N4A== X-Gm-Message-State: AOAM531zwUv0LaPWCWLp6oDuOVtOdnDQZJY7kjdy7QRk44zZmcrwC12Y ZZpiub+BX4n8twpDF076fNV2tRmUP8ePPQ== X-Google-Smtp-Source: ABdhPJwI/PE3FxpyrneYpnzVZtCYsXt6L7gZ7czIc+iaKdjooAqj4oJjYf7d3g6BvOXRWjtTS3zbFw== X-Received: by 2002:a05:6830:408c:b0:5b2:352a:dc83 with SMTP id x12-20020a056830408c00b005b2352adc83mr243458ott.152.1649092937020; Mon, 04 Apr 2022 10:22:17 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:a6c0:94cf:60bc:16d1:2727? ([2804:431:c7cb:a6c0:94cf:60bc:16d1:2727]) by smtp.gmail.com with ESMTPSA id n62-20020acaef41000000b002ef646e6690sm4562050oih.53.2022.04.04.10.22.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Apr 2022 10:22:16 -0700 (PDT) Message-ID: <899d390b-40ed-3b85-a2d9-6f11b2c8ebe3@linaro.org> Date: Mon, 4 Apr 2022 14:22:14 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH v1 1/2] random-bits: Factor out entropy generating function Content-Language: en-US To: libc-alpha@sourceware.org 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> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 17:22:19 -0000 On 04/04/2022 13:51, Noah Goldstein via Libc-alpha wrote: > 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 a user exported ABI I think it would be better to rehearse the arc4random proposal, which I might spend some time to come with a simpler solution based on Florian proposal. For this specif proposal, I see that just factoring the code to make only x86 use the rdtsc should be suffice. Ideally, if we eventually get an arc4random the idea would be use it instead. Florian initial proposal aimed to use AES so we can leverage hardware assisted optimization presented in some chips.