From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4A7BC43381 for ; Tue, 26 Mar 2019 16:25:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8C07F206DF for ; Tue, 26 Mar 2019 16:25:30 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=sdf.org header.i=@sdf.org header.b="etBlD3aq" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730537AbfCZQZ3 (ORCPT ); Tue, 26 Mar 2019 12:25:29 -0400 Received: from mx.sdf.org ([205.166.94.20]:53173 "EHLO mx.sdf.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727492AbfCZQZ3 (ORCPT ); Tue, 26 Mar 2019 12:25:29 -0400 Received: from sdf.org (IDENT:lkml@sdf.lonestar.org [205.166.94.16]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id x2QGOxRs012381 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Tue, 26 Mar 2019 16:25:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sdf.org; s=default; t=1553617505; bh=7ODRKSo+EDtCvdD1FafI3ByypHr0ooqugefGlSwdHOY=; h=Date:From:To:Subject:Cc:In-Reply-To:References; b=etBlD3aq/T3XD3axK/RoxdK/UbdbKCIaIsOX0rT5GtHFTYUsdpAJtr2UqoiVfxNDF oLU2nxlb/0M6Lqz6pv6LiSMQAGUT9lNU6g0JsQgud6/dZ0gOdzwWotv5Kblp+gdI6C pqI4KasRzQfxLlVweEdK3OimZjoUaJrFBrtmRuBA= Received: (from lkml@localhost) by sdf.org (8.15.2/8.12.8/Submit) id x2QGOxOV006525; Tue, 26 Mar 2019 16:24:59 GMT Date: Tue, 26 Mar 2019 16:24:59 GMT From: George Spelvin Message-Id: <201903261624.x2QGOxOV006525@sdf.org> To: lkml@sdf.org, stephen@networkplumber.org Subject: Re: Revising prandom_32 generator Cc: daniel@iogearbox.net, hannes@stressinduktion.org, netdev@vger.kernel.org In-Reply-To: <20190326075839.5a94442b@shemminger-XPS-13-9360> References: <201903261110.x2QBAFmp001613@sdf.org>, <20190326075839.5a94442b@shemminger-XPS-13-9360> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > A little backstory. I started the prandom_32 stuff long ago when I wanted > a better (longer period) PRNG for use in netem. Took the existing code from > older version of GNU scientific library (pre GPLv3). If there is something > faster with better properties go for it. But the whole point of prandom_32 > is that it doesn't have to be crypto quality. Than you for the encouragement! The lfsr113 generator is really a perfectly respectable generator. There's nothing about it that "needs fixing"; it's just possible to do slighty better. When I can get better statistics, longer period (for the same state size), faster *and* smaller code size, it seems worth looking into. And yes, I understand "pseudorandom" very well. From a documentation patch for drivers/char/random.c I also posted recenty: + * + * prandom_u32() + * ------------- + * + * For even weaker applications, see the pseudorandom generator + * prandom_u32(), prandom_max(), and prandom_bytes(). If the random + * numbers aren't security-critical at all, these are *far* cheaper. + * Useful for self-tests, random error simulation, randomized backoffs, + * and any other application where you trust that nobody is trying to + * maliciously mess with you by guessing the "random" numbers.