View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001926 | 1003.1(2024)/Issue8 | Base Definitions and Headers | public | 2025-05-31 15:24 | 2025-06-12 15:42 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Clarification Requested |
| Status | Resolved | Resolution | Accepted As Marked | ||
| Name | DannyNiu/NJF | ||||
| Organization | Individual | ||||
| User Reference | C243.pdf | ||||
| Section | <limits.h> :: Other Invariant Values :: {GETENTROPY_MAX} | ||||
| Page Number | 293 | ||||
| Line Number | 10226-10228 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001926:0007203 | ||||
| Summary | 0001926: Nobody has mistaken bytes for bits when deciding value for GETENTROPY_MAX do we? | ||||
| Description | {GETENTROPY_MAX} is currently defined to be 256, which means we can use getentropy(2) to generate 2048-bit pseudo-random data. As an quality of implementation issue, how much actual entropy is present may be immaterial; but in reality, officially approved cryptographically-secure pseudo-random number generators and their concrete instantiation parameters provide much less than that. It's more likely in reality that actual entropy provided in even 256-byte (i.e. 2048-bit) data is at most 256-bit (i.e. 32-byte), or occasionally, 512-bit (i.e. 64-byte). | ||||
| Desired Action | Consider amending the specified minimum for {GETENTROPY_MAX}, taking real-world CSPRNG algorithms and constructions into consideration. | ||||
| Tags | tc1-2024 | ||||
|
|
I'd like to amend the desired action to a clarification that explains GETENTROPY_MAX is not meant to indicate the actual entropy that one can obtain from the call, but as a limit which when exceeded, the implementation is allowed to fail. |
|
|
The text on the <limits.h> page referred to here simply states that the value is "The maximum value of the length argument in calls to the getentropy( ) function." It says nothing about the entropy obtained. There is a matching EINVAL error on the getentropy() page. The only possible problematic text is at the end of the getentropy() DESCRIPTION: "A successful call to getentropy( ) shall always provide the requested number of bytes of entropy." I believe this was taken directly from the glibc man page (the only change being the use of "shall"). |
|
|
Given that the first paragraph of DESCRIPTION has detailed requirements on the data produced, and the NAME section says "fill a buffer with random bytes", a possible solution would be to change:A successful call to getentropy( ) shall always provide the requested number of bytes of entropy. to: A successful call to getentropy( ) shall always provide the requested number of random bytes. |
|
|
I suggest in APPLICATION USAGE: > The intended use of this function is to create a seed for other pseudo-random number generators. to > The intended use of this function is to create a seed for other pseudo-random number generators, and to generate keys, nonces, and other cryptographic components. And in RATIONALE explain that most CSPRNG algorithms and their instantiation parameters typically provide 256-bit security, and that generating beyond 512 random bits almost certainly don't offer that much entropy. |
|
|
Change Page 1119 Line 38387 from:A successful call to getentropy( ) shall always provide the requested number of bytes of entropy. To: A successful call to getentropy( ) shall always provide the requested number of random bytes. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2025-05-31 15:24 | dannyniu | New Issue | |
| 2025-05-31 15:38 | dannyniu | Note Added: 0007192 | |
| 2025-06-03 09:37 | geoffclare | Note Added: 0007193 | |
| 2025-06-03 10:13 | geoffclare | Note Added: 0007194 | |
| 2025-06-03 10:14 | geoffclare | Note Edited: 0007194 | |
| 2025-06-03 11:51 | dannyniu | Note Added: 0007195 | |
| 2025-06-03 11:55 | dannyniu | Note Edited: 0007195 | |
| 2025-06-03 11:56 | dannyniu | Note Edited: 0007195 | |
| 2025-06-12 15:41 | geoffclare | Note Added: 0007203 | |
| 2025-06-12 15:42 | geoffclare | Status | New => Resolved |
| 2025-06-12 15:42 | geoffclare | Resolution | Open => Accepted As Marked |
| 2025-06-12 15:42 | geoffclare | Interp Status | => --- |
| 2025-06-12 15:42 | geoffclare | Final Accepted Text | => 0001926:0007203 |
| 2025-06-12 15:42 | geoffclare | Tag Attached: tc1-2024 |
