| 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: <87ej2untze.fsf@basil.nowhere.org> Date: Mon, 06 Oct 2008 08:00:21 +0200 From: Andi Kleen <andi@...stfloor.org> To: Kees Cook <kees.cook@...onical.com> Cc: Roland McGrath <roland@...hat.com>, linux-kernel@...r.kernel.org, Jakub Jelinek <jakub@...hat.com>, Ulrich Drepper <drepper@...hat.com>, libc-alpha@...rceware.org Subject: Re: [PATCH] ELF: implement AT_RANDOM for future glibc use Kees Cook <kees.cook@...onical.com> writes: > While discussing[1] the need for glibc to have access to random bytes > during program load, it seems that an earlier attempt to implement > AT_RANDOM got stalled. This implements a configurable number of random > bytes available to every ELF program via a new auxv AT_RANDOM vector. While the basic idea is good using get_random_bytes() is not. That eats precious cryptography strength entropy from the entropy pool, which on many systems is not adequately fed. In those cases you really only want to use it for real keys, not for lower grade applications. The applications glibc wants to use this for do not really require crypto strength entropy, just relatively unpredictable randomness. What you should instead do is to initialize some other cryptographic RNG regularly and use the output of that. -Andi -- 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