From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 654993858C83 for ; Tue, 19 Jul 2022 17:31:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 654993858C83 Received: by mail-oi1-x236.google.com with SMTP id j70so7675561oih.10 for ; Tue, 19 Jul 2022 10:31:56 -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=X91GxCKuWWM135acTvKeP4EFrgfSWlpwAO8mfGqhXjE=; b=Zuzlddp20FpHAyD6y6YgcXnlyljLHPVDKAtEdOxNn2FK+p9sh4sJGjUrPLgQ3lV2Pa wuhn9AiB9dz7PreUVwYYvQdYM+H2XFwok20eVxo3eYLfKcRTpT0X4kcHvnE6vpzifZo4 ss3+A2QzbpJKQcw4sP1/0/dPckBV9m1Gg+BwG1T45lciUdXaLN0TY6T4qtORIPLcsLKt MmFRr1fHOLtpckWu7yjuJS05ENE78ZTJCwV5f5yK2PGM5BSEaomsDmEzozNHCoHYdaVX FQyDP2MJc+pV8S4jHlCKEA76/LyoPAYUnmyWcsp/9QVS+7AK3ZHnwgLUJHoXcqFMlf3G GbLw== X-Gm-Message-State: AJIora85Wj9xA6T8o3T/sSFVPsXNkTp7HO/G2jJAP1Skr4QYXAWBKvit T3pwqaZ+ntQfQhkFu/IlXefSJ9m6l7sT4wsp X-Google-Smtp-Source: AGRyM1sZwysbJoFs+8xqK5h3TDX7XiKei/o6Aky2AY9+jHYEjKFgQ9mNSbRHy61t3IzS0aYVVL23cA== X-Received: by 2002:a05:6808:1148:b0:339:b283:a1e7 with SMTP id u8-20020a056808114800b00339b283a1e7mr253256oiu.92.1658251915667; Tue, 19 Jul 2022 10:31:55 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:19c3:dd8:aab0:e2e6:308b? ([2804:431:c7ca:19c3:dd8:aab0:e2e6:308b]) by smtp.gmail.com with ESMTPSA id t24-20020a4ae418000000b004359b581401sm2524452oov.25.2022.07.19.10.31.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Jul 2022 10:31:55 -0700 (PDT) Message-ID: Date: Tue, 19 Jul 2022 14:31:53 -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.2 Subject: Re: [PATCH v10 9/9] manual: Add documentation for arc4random functions Content-Language: en-US To: =?UTF-8?Q?Cristian_Rodr=c3=adguez?= , Florian Weimer Cc: libc-alpha@sourceware.org References: <20220714112845.704678-1-adhemerval.zanella@linaro.org> <20220714112845.704678-10-adhemerval.zanella@linaro.org> <87h73ezh0d.fsf@oldenburg.str.redhat.com> <87wncaxyqb.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.1 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: Tue, 19 Jul 2022 17:31:58 -0000 On 19/07/22 14:13, Cristian Rodríguez wrote: > On Mon, Jul 18, 2022 at 10:49 AM Florian Weimer wrote: >> >> * Cristian Rodríguez: >> >>>> I think it's more important to make sure that unmodified glibc can be >>>> used in a certified environment. Our implementation is not certifiable >>>> because it's not using an approved algorithm. The OpenBSD >>>> implementation has the same issue: in a certified environment, it either >>>> has not be documented as not cryptographically secure, or it has to be >>>> implemented on top of an approved algorithm. >> >>> In that case the linux kernel is also non certified.. whatever..maybe >>> omit the paragraph all together. >> >> These certified configurations already need a patched/custom kernel. >> But we don't want to add a patched glibc as an additional burden. >> >> Thanks, >> Florian > > Then why not add a tunable where the api just calls getrandom y you > already have a patched kernel? Why not just call getrandom then? If you really need a CSPRNG best course of action is actually to ask kernel for more entropy. I don't see much gain in adding a tunable where glibc *already* provides a API to access such interface (worse case the program will need to /dev/urandom, but it also means the kernel is old). > Come on, a tiny amount of users need to comply with FIPS.. one could > also want to use DJB fast key erasure RNG with AES-Ni.. but again it > won't comply .. nothing sane does.