From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2c.google.com (mail-oa1-x2c.google.com [IPv6:2001:4860:4864:20::2c]) by sourceware.org (Postfix) with ESMTPS id BF8453857809 for ; Mon, 25 Jul 2022 15:59:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BF8453857809 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-1013ecaf7e0so15242032fac.13 for ; Mon, 25 Jul 2022 08:59:43 -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:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=MQ1TuRAqAB9FQ9er/Dx0aITtQ81Ea93wYVpkDOTZzNs=; b=pIy0bEdZJjP/ALYlH5+pCh73Z7yLiIAJh6wulpjGnQkJ57XbHAQ68PIYxtzLB5i2YY hB3ngTStgTW4HIAphMVSGEuoffCXtjbPaaWk0/mIiO2LDBvRuYEZy+7vWDSH9K4fa5wq gz0RuO9MhqTsMzhmd46+KAHZHW+YdchCE5P8pVQ2cP8jstp4JB2U8T4B2FbyKBxjlKcN REYCpD+6ZyYuI8IBKITazB31jK5tf3cQRy8QDf58PL7vbW9awTi0NQ3zU05HhAVL7vfC D4lR8P1opTUIaJ1uWOyQrUUZN3ti3iyKJwXW4nB3hF/XSMkGNwG7SrV93b2dqAZpmXdh +S0g== X-Gm-Message-State: AJIora+T6pZlcsM9QWddW4BHPn8DoxZpCJxBs1kFS+aemBQnObvXWxRj P7rgC/WcsVf7yobn4WQb58VtKQ== X-Google-Smtp-Source: AGRyM1tEAR38JaQeLCAcf7mUueDz5hxuBdVAbVtT+pquLtTZVrgdMHIWovxTffXp+PCMPDuIFCTUZA== X-Received: by 2002:a05:6870:a782:b0:10d:d341:faf7 with SMTP id x2-20020a056870a78200b0010dd341faf7mr6017835oao.278.1658764783073; Mon, 25 Jul 2022 08:59:43 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:8ded:894b:344:2c82:9bb5? ([2804:431:c7cb:8ded:894b:344:2c82:9bb5]) by smtp.gmail.com with ESMTPSA id l4-20020a9d7084000000b00616d25dc933sm5063976otj.69.2022.07.25.08.59.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Jul 2022 08:59:42 -0700 (PDT) Message-ID: Date: Mon, 25 Jul 2022 12:59:39 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.0.3 Subject: Re: arc4random - are you sure we want these? Content-Language: en-US To: Rich Felker Cc: "Jason A. Donenfeld" , libc-alpha@sourceware.org, Florian Weimer , Yann Droneaud , jann@thejh.net, Michael@phoronix.com, Paul Eggert References: <6bf352e9-1312-40de-4733-3219721b343c@linaro.org> <20220725153303.GF7074@brightrain.aerifal.cx> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <20220725153303.GF7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.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 autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 25 Jul 2022 15:59:45 -0000 On 25/07/22 12:33, Rich Felker wrote: > > If this is just a case of trying to be "cautious" about overpromising > things, the documentation needs fixed to specify that this is a > CSPRNG. I'm particularly worried about the wording "these still use a > Pseudo-Random generator and should not be used in cryptographic > contexts". *All* CSPRNGs are PRNGs. Being pseudo-random does not make > it not cryptographically safe. The safety depends on the original > source of the entropy and the practical irreversibility and other > cryptographic properties of the extension function. The fact that this > has been stated so poorly in the documentation really has me worried > that someone does not understand the issues. I haven't dug into the > list mails or actual code to determine to what extent that's the case, > but it's really, *really* worrying. That's the main drive to avoid calling CSPRNGs, since nor me or Florian is secure enough to certify current scheme can actually follow all the requirements. It does follow OpenBSD strategy of a fast-key-erasure random-number generators, although all strategies of key reseeding are basically heuristics. If I understand Jason argument correctly, unless we have a kernel API which it actually handles the buffer (so it can reseed or clear when it seems fit), there is no point is proving a CSPRNGs in userspace, use getrandom instead.