| lists.openwall.net | 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 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <52CFE84A.9050107@ladisch.de> Date: Fri, 10 Jan 2014 13:32:10 +0100 From: Clemens Ladisch <clemens@...isch.de> To: Stephan Mueller <stephan.mueller@...ec.com> CC: Rafael Aquini <aquini@...hat.com>, Theodore Ts'o <tytso@....edu>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org Subject: Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed Stephan Mueller wrote: > Am Freitag, 10. Januar 2014, 12:37:26 schrieb Clemens Ladisch: >> Stephan Mueller wrote: >>> Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: >>>> Rafael Aquini wrote: >>>>> This patch introduces changes to the random_write method so it can >>>>> split the given seed and completely stir the output pools with >>>>> different halves of it, when seed lenght allows us doing so. >>>>> >>>>> - ret = write_pool(&blocking_pool, buffer, count); >>>>> + ret = write_pool(pool1, buffer, count1); >>>>> >>>>> if (ret) >>>>> >>>>> return ret; >>>>> >>>>> - ret = write_pool(&nonblocking_pool, buffer, count); >>>>> + ret = write_pool(pool2, buffer + offset, count2); >>>> >>>> Doesn't this assume that both halves of the buffer contain some >>>> (uncredited) entropy? In other words, wouldn't this result in worse >>>> randomness for pool2 if the second half of the buffer contains just >>>> zero padding? >>> >>> [...] >>> Coming back to your concern: sure, the caller can pad any data >>> injected into /dev/?random with zeros. >> >> Assume that the userspace of an embedded device wants to do the same >> kind of initialization that a call to add_device_randomness() does, and >> that it has some data like "char serial_number[256]". The padding >> wouldn't be done intentionally, it's just a property of the data (and >> it wouldn't have mattered before this patch). >> >>> But as writing to the character files is allowed to every user, this >>> per definition must not matter (e.g. an attacker may simply write >>> zeros or other known data into the character file). And the random.c >>> driver handles that case appropriately by not increasing the entropy >>> estimator when receiving data. >> >> The problem is not with the entropy estimate. >> >>> All the patch tries to achieve is to ensure that both pools are not >>> always mixed with the same values. >> >> Before this patch, both pools got mixed with the same values. After >> this patch, both pools indeed get mixed with different values, but now >> one pool gets mixed with a known value if one half of the buffer >> happens to be known. > > Do you imply in your example above that the serial number is unknown? > Anything that unprivileged user space tries to inject into /dev/?random > should be considered data with known value. Like the kernel's add_device_randomness() function, this example assumes that there is no persistent storage with a saved seed (or that it isn't yet available), and that mixing a device-specific value at least prevents multiple device instances from generating identical random numbers. This indeed helps only against attackers that do not know that serial number. If the data written by unprivileged users to /dev/?random were considered known to *all* attackers, then it wouldn't make sense to allow such writes at all. Regards, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists