From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51474 invoked by alias); 29 Sep 2017 23:58:53 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 50683 invoked by uid 89); 29 Sep 2017 23:58:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=toward, delighted, rng, RNG X-HELO: mailbackend.panix.com X-Gm-Message-State: AMCzsaWrBlNawORNADMAB2o8g5GZtojjC5R1Q4mqX0reWIMAcch5iIF/ HBpG0+Ngm7qyUoeCZbGRk3LTcPONNK+wzh0NOMY= X-Google-Smtp-Source: AOwi7QBpCB8kf2Qgk312TYu4cPnEA5Yejhry5+8ZZg8G5iwTaGXyjoVoEhmqLf7cekisLZkiAfyGLKa88ar5WHYVXbU= X-Received: by 10.157.55.162 with SMTP id x31mr3570276otb.224.1506729528651; Fri, 29 Sep 2017 16:58:48 -0700 (PDT) MIME-Version: 1.0 From: Zack Weinberg Date: Fri, 29 Sep 2017 23:58:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: arc4random (was Re: Remove add-ons mechanism) To: Florian Weimer Cc: Joseph Myers , GNU C Library Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-09/txt/msg01168.txt.bz2 On Fri, Sep 29, 2017 at 7:04 AM, Florian Weimer wrote: > On 09/29/2017 12:01 AM, Zack Weinberg wrote: >> I don't disagree with this patch exactly, but I was thinking of using >> the add-ons mechanism to prototype a CSPRNG addition to glibc > > I've got something towards an implementation of arc4random (not certifiable, > but it should be unpredictable in practice). I'm delighted to hear that, and please let me know if i can help in any way. I don't have a whole lot of time toward libc hacking this cycle but I would really like to see it done this cycle, so I'll find the time. :) > I think I found a way to do full fork protection even without > MADV_WIPEONFORK, using a global counter in a MAP_SHARED segment. Reseeding > is still needed to deal with a counter overflow on 32-bit architectures, and > there is some overhead by the globally shared counter, but I think it is > superior to all approaches I've seen so far (and it does not require a fork > handler or a system call for every random number generation). Is the idea that after a fork, processes may share RNG state but they see each others' counter increments so they won't return the same random bits from paired calls? Kind of like how it would work for multiple threads with a shared but atomically accessed RNG state? zw