From owner-freebsd-hackers@freebsd.org Thu Jul 12 17:32:12 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26B2B102A9FA for ; Thu, 12 Jul 2018 17:32:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9826A74BCC for ; Thu, 12 Jul 2018 17:32:11 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it0-f44.google.com with SMTP id y124-v6so2552391itc.0 for ; Thu, 12 Jul 2018 10:32:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=kB98vhgTiKCC6BZnC5GZm4VzjJwvQe4rD77JZkSxOUA=; b=bSF45T3lKH+PWx2Q0c1do7Ccg0pxBQvkgkbi7ucBt2v+WzcQgqQY5iTE3Cj9ObnmzD JJJWZYCangGD7K8OLLffVYmuL096b5y4QF+TBt/eZT8grxRjg0hD/qib8yLNzlOZIfm6 gnjvNEy3f+NiWQ7BfMJQ+wkUj/XG4NcmC1U5v7yZqw+BTRQc5Bh/72FXakRWQe0xi8LH vVPOxculi9xNYUHRI1SruqHExHGRlTC4rKEz3EMhZg63Qk9CI7sLbzSrrFpyx4kddrnt 5DCfOxlvrP1yGAbf2ylQx/nkYodqBnTAbf8QZSMOMHc6hu1vVzeZvPGguVpBhU7O+WCQ 9fHQ== X-Gm-Message-State: AOUpUlExggcxOjQbQcsrTrBvbKaQS17i8H5szbbQ1UNl3JMnmrtYC/89 Qsya1H3D3ecl4nZoy9WpT3Ewe6zl X-Google-Smtp-Source: AAOMgpcm4NCdHrDbdn+kgoeHmXv1RqKdZxQ5nS73WCqSRNmkgvbDibc/3QPpNCYRZpmFsP9pCT17cw== X-Received: by 2002:a24:4dc1:: with SMTP id l184-v6mr2045976itb.20.1531416724546; Thu, 12 Jul 2018 10:32:04 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id n11-v6sm2919537itn.40.2018.07.12.10.32.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 10:32:04 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id p4-v6so7937823itf.2 for ; Thu, 12 Jul 2018 10:32:04 -0700 (PDT) X-Received: by 2002:a24:a343:: with SMTP id p64-v6mr2147850ite.61.1531416724253; Thu, 12 Jul 2018 10:32:04 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 10:32:03 -0700 (PDT) In-Reply-To: <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> From: Conrad Meyer Date: Thu, 12 Jul 2018 10:32:03 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Limits to seeding /dev/random | random(4) To: Dirk-Willem van Gulik Cc: RW , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 17:32:12 -0000 On Thu, Jul 12, 2018 at 9:03 AM, Dirk-Willem van Gulik wrote: > On 12 Jul 2018, at 17:57, RW via freebsd-hackers wrote: >> On Wed, 11 Jul 2018 07:58:35 -0600 Ian Lepore wrote: >> >>> When asking our prng gurus for advice on writing a device driver for >>> an on-chip entropy source, the advice I got was basically: there's no >>> need to feed in more entropy on an ongoing basis, but no harm in >>> doing so either, within reason. The recommendation was to feed at or >>> below an average rate of about 128 bits/second. Pushing in more isn't >>> harmful, just wasteful of system resources because it doesn't make >>> anything better. >> >> This is a bit simplistic because it ignores the way that fortuna >> stripes entropy across 32 pools. RW, you and Ian are talking about different things. Ian is talking about post-seed, additional entropy from a hardware device. You are talking about initial seeding. You're both right, but talking past each other :-). >> In order to fully secure the prng at boot time you need to get 256 bits >> of entropy into it, and to guarantee that you need to have 256 bits in >> pool[0], which means you need to write 256*32=3D8192 bits into the rando= m >> device. This should be done as early in the rc.d boot process as >> possible. For example, it is done by the loader, as well as the /etc/rc.d/random script using entropy saved from the RNG at shutdown on any FreeBSD with a writable /, /var, or /boot. >> Once the pools are primed you could trickle entropy in in >> smaller amounts if you wish. Right =E2=80=94 that's what Ian is suggesting. > So these HW devices [1] give us a raw feed =E2=80=94 which one usually wh= itewashes [2] in order to use. Don't feed the raw data =E2=80=94 use the washed bits. > It is fairly well defined how many bits of entropy we get =E2=80=98raw=E2= =80=99. > > During boot - can I feed the right number of bits without whitewashing - = letting the kernel do the trick (much like random_harvest_queue() does in f= or example the mouse driver) ? Why feed less random data to the kernel when you have a relatively high throughput random device available? Your device generates 90 kbps after washing =E2=80=94 it'll take at most 90 ms to fully seed /dev/random at that rate, even with a readonly filesystem embedded-type device. > Or should it be properly whitened first ? Yes :-). > Our goal is to get to a point where a very stripped down BSD can be boote= d up (sans network or much in terms of attached devices but for a printer a= nd chipcard reader) =E2=80=94 yet is know to have a solid seeded RNG. /dev/u?random never produces unseeded results. If it is not seeded, reads will just block indefinitely, until it is seeded. To seed the device without a writable filesystem, write 1kB+ of whitened random from your device into /dev/random early in boot, and you will be good to go. You can do the ongoing trickle after that if you want, but it is not necessary. On FreeBSD 12-CURRENT, you can verify /dev/random is seeded when getrandom(..., GRND_NONBLOCK) no longer returns -1 with EAGAIN errno. If you need to use a FreeBSD prior to 12, you'll know random is seeded when reads no longer block. All the best, Conrad