You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
There are some circumstances where software (validly) needs high-quality random numbers, such as for cryptographic algorithms. The ISO C standard API is not sufficient, as functions like rand() are only psuedo-random and thus are not useful for algorithms where true randomness is necessary.
Furthermore, to support the notion of "fuzz testing" the UT assert framework should also have a facility to easily get random numbers.
Describe the solution you'd like
Many OS's have a facility to interface with a true hardware random number generator or get much higher-quality random numbers through software by gathering entropy from a local platform-specific source (like keystrokes or mouse movements, or electrical noise from an ADC, etc).
Describe alternatives you've considered
Initially, this can be as simple as calling srand() once during startup with an unpredictable value, or the system clock tick counter if no real random source is available. This way, if the application does call rand(), the numbers at least will not be the same every time.
That would be good enough for low impact tasks like fuzz testing and things of that nature, but wouldn't be sufficient for crypto.
Additional context
To clarify - fuzz testing described here is a functional test concept, independent of coverage testing. For coverage testing using UT assert, it is important that the test case follows predictable branches, and thus random numbers should not be used there. Fuzz testing, if implemented, would be done as a completely separate test.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
There are some circumstances where software (validly) needs high-quality random numbers, such as for cryptographic algorithms. The ISO C standard API is not sufficient, as functions like
rand()
are only psuedo-random and thus are not useful for algorithms where true randomness is necessary.Furthermore, to support the notion of "fuzz testing" the UT assert framework should also have a facility to easily get random numbers.
Describe the solution you'd like
Many OS's have a facility to interface with a true hardware random number generator or get much higher-quality random numbers through software by gathering entropy from a local platform-specific source (like keystrokes or mouse movements, or electrical noise from an ADC, etc).
Describe alternatives you've considered
Initially, this can be as simple as calling
srand()
once during startup with an unpredictable value, or the system clock tick counter if no real random source is available. This way, if the application does callrand()
, the numbers at least will not be the same every time.That would be good enough for low impact tasks like fuzz testing and things of that nature, but wouldn't be sufficient for crypto.
Additional context
To clarify - fuzz testing described here is a functional test concept, independent of coverage testing. For coverage testing using UT assert, it is important that the test case follows predictable branches, and thus random numbers should not be used there. Fuzz testing, if implemented, would be done as a completely separate test.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: