rfc:csrandombytes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:csrandombytes [2012/01/08 16:11] – [Current PHP APIs to the syetem CSPRNG] fsbrfc:csrandombytes [2021/03/27 14:30] (current) – Move to inactive ilutov
Line 3: Line 3:
   * Date: 2012 Jan 8   * Date: 2012 Jan 8
   * Author: Tom Worster <fsb@thefsb.org>   * Author: Tom Worster <fsb@thefsb.org>
-  * Status: Draft+  * Status: Inactive 
 +  * Sandbox: https://github.com/tom--/php-cs_random_bytes
  
 Platform and extension-independent API to the system CSPRNG Platform and extension-independent API to the system CSPRNG
Line 48: Line 49:
 There are two reasons why this situation is unsatisfactory. First, PHP programmers should be able to write scripts that use CS random data without risking failure in the field due to unfortunate configuration of the production environment. The programmer, after all, may have no influence over the production environment and might not be in a position to dictate requirements. Nevertheless, the programmer may want to protect her reputation by delivering quality software that can reasonably be expected work securely many years into the future on PHP systems of configuration she cannot predict. There are two reasons why this situation is unsatisfactory. First, PHP programmers should be able to write scripts that use CS random data without risking failure in the field due to unfortunate configuration of the production environment. The programmer, after all, may have no influence over the production environment and might not be in a position to dictate requirements. Nevertheless, the programmer may want to protect her reputation by delivering quality software that can reasonably be expected work securely many years into the future on PHP systems of configuration she cannot predict.
  
-Second, even if the probability that all 5 of the methods described above fail were vanishingly small, such a process is unacceptably complex. It demands a degree of sophistication and volume of code that is out of keeping with the task—it should be as simple as calling a function similar to openssl_random_pseudo_bytes(). More importantly, it is difficult to test such software because it requires many different runtime systems to exercise all braches. +Second, even if the probability of failure of all 5 of the methods described above were vanishingly small, such a process is unacceptably complex. It demands a degree of sophistication and volume of code that is out of keeping with the task, which should be as simple as calling a function similar to openssl_random_pseudo_bytes(). More importantly, it is difficult to test such software because it requires many different runtime systems to exercise all its braches. 
  
 ==== Does anything need to be done? ==== ==== Does anything need to be done? ====
Line 64: Line 65:
 This function shuld have a parameter specifying the number of random bytes the caller requests. The return value is a string of the requested byte length, the value being provided by the system CSPRNG. This function shuld have a parameter specifying the number of random bytes the caller requests. The return value is a string of the requested byte length, the value being provided by the system CSPRNG.
  
-The function should neither block nor return a failure status in the case that the systems entropy pool is depleted. However, it should allow the caller to discover if this is the case. Thus it should behave as openssl_random_pseudo_bytes() does, continuing to return bytes from the system CSPRNG even when its entropy sources are low and offering a flag it sets if the caller reads beyond what the CSPRNG considers secure. In other words, it should neither behave like /dev/random on Linux, which blocks when entropy is low, nor like mcrypt_create_iv(), which can return insecure results without the caller’s knowledge.  +The function should neither block nor return a failure status in the case that the systems entropy pool is depleted. However, it should allow the caller to discover if this is the case. Thus it should behave as openssl_random_pseudo_bytes() does, continuing to return bytes from the system CSPRNG even when its entropy sources are low and offering a flag that is set if the caller reads beyond what the CSPRNG considers secure. In other words, it should neither behave like /dev/random on Linux, which blocks when entropy is low, nor like mcrypt_create_iv(), which can return insecure results without the caller’s knowledge.
-owledge.+
  
- 
-==== Rejected Features ==== 
- 
-Automated voting system. 
  
 ===== Changelog ===== ===== Changelog =====
rfc/csrandombytes.1326039084.txt.gz · Last modified: 2017/09/22 13:28 (external edit)