A NOTE has been added to this issue. ====================================================================== http://austingroupbugs.net/view.php?id=1134 ====================================================================== Reported By: nmav Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1134 Category: System Interfaces Type: Enhancement Request Severity: Editorial Priority: normal Status: New Name: Nikos Mavrogiannopoulos Organization: Red Hat User Reference: Section: getentropy Page Number: 0 Line Number: 0 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2017-03-31 07:06 UTC Last Modified: 2017-04-06 20:00 UTC ====================================================================== Summary: Add getentropy interface ====================================================================== Relationships ID Summary ---------------------------------------------------------------------- related to 0000859 Add posix_random family of interfaces ======================================================================
---------------------------------------------------------------------- (0003662) shware_systems (reporter) - 2017-04-06 20:00 http://austingroupbugs.net/view.php?id=1134#c3662 ---------------------------------------------------------------------- IIRC, Bug 859 was tentatively approved partly because PRNGs can be implemented entirely in software. Perceived randomness was therefore a function of algorithm quality and usage. An interface like this more assumes motherboards or CPUs all have peripherals that are designed to generate these uniformly random sequences independently, to guarantee they are 'cryptographically secure' in the black box sense, and few commercial systems, if any, that I'm aware of actually provide this type of hardware. Many have hardware that can provide values random enough looking, possibly, to be a PRNG seed value, but not securely so or dedicated to this purpose. This lack of hardware is why, I believe, many PKCS key generators rely on the effective randomness of an operator moving a mouse around as their seed source. That said, I agree adding something along these lines is desirable for uniformity of usage, but I don't see it as a candidate for the Base. It should be marked part of the CRYPT Option Group, and the ENOSYS error should use wording consistent with the other members of that group. No POSIX system is required to use a system call paradigm, after all; hardware accesses can be coded directly into the C library. Issue History Date Modified Username Field Change ====================================================================== 2017-03-31 07:06 nmav New Issue 2017-03-31 07:06 nmav Name => Nikos Mavrogiannopoulos 2017-03-31 07:06 nmav Organization => Red Hat 2017-03-31 07:06 nmav Section => getentropy 2017-03-31 07:06 nmav Page Number => 0 2017-03-31 07:06 nmav Line Number => 0 2017-03-31 07:17 Don Cragun Relationship added related to 0000859 2017-04-01 06:25 EdSchouten Note Added: 0003657 2017-04-06 09:46 nmav Note Added: 0003660 2017-04-06 20:00 shware_systems Note Added: 0003662 ======================================================================
