lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 14 Feb 2020 14:55:36 -0800
From:   Mark Salyzyn <>
To:     "Theodore Y. Ts'o" <>, Rob Herring <>
Cc:     Masami Hiramatsu <>,
        "" <>,
        Android Kernel Team <>,
        Arnd Bergmann <>,
        Greg Kroah-Hartman <>,
        Richard Henderson <>,
        Mark Brown <>,
        Kees Cook <>,
        Hsin-Yi Wang <>,
        Vasily Gorbik <>,
        Andrew Morton <>,
        Steven Rostedt <>,
        Mike Rapoport <>,
        Arvind Sankar <>,
        Dominik Brodowski <>,
        Thomas Gleixner <>,
        Alexander Potapenko <>,
        Jonathan Corbet <>,
        Mauro Carvalho Chehab <>,
        Josh Poimboeuf <>,
        Pawan Gupta <>,
        Juergen Gross <>,
        Linux Doc Mailing List <>
Subject: Re: [PATCH 2/3] random: rng-seed source is utf-8

On 2/14/20 2:47 PM, Theodore Y. Ts'o wrote:
> On Fri, Feb 14, 2020 at 01:58:35PM -0600, Rob Herring wrote:
>> On Fri, Feb 14, 2020 at 12:10 AM Masami Hiramatsu <> wrote:
>>> From: Mark Salyzyn <>
>>> commit 428826f5358c922dc378830a1717b682c0823160
>>> ("fdt: add support for rng-seed") makes the assumption that the data
>>> in rng-seed is binary, when it is typically constructed of utf-8
>> Typically? Why is that?
>>> characters which has a bitness of roughly 6 to give appropriate
>>> credit due for the entropy.
> This is why I really think what gets specified via the boot command
> line, or bootconfig, should specify the bits of entropy and the
> entropy seed *separately*, so it can be specified explicitly, instead
> of assuming that *everyone knows* that rng-seed is either (a) a binary
> string, or (b) utf-8, or (c) a hex string.  The fact is, everyone does
> *not* know, or everyone will have a different implementation, which
> everyone will say is *obviously* the only way to go....
> 	      	     		     	  - Ted

Given that the valid option are between 4 (hex), 6 (utf-8) or 8 
(binary), we can either split the difference and accept 6; or take a 
pass at the values and determine which of the set they belong to 
[0-9a-fA-F], [!-~] or [\000-\377]  nor need to separately specify.

-- Mark

Powered by blists - more mailing lists