fix readme typos etc
This commit is contained in:
parent
6aa14a75d4
commit
057f41dcd2
22
README.md
22
README.md
|
@ -25,8 +25,8 @@ whitening/compression step based on [Ascon](https://ascon.iaik.tugraz.at/)-Xofa.
|
|||
## Requirements
|
||||
|
||||
* Pico C SDK
|
||||
* System must not run from ROSC, and the system clock must be at least 48 MHz
|
||||
(80 MHz or higher preferred, 125 MHz or higher ideal).
|
||||
* System must not run from ROSC
|
||||
* System clock must be at least 48 MHz (80 MHz or higher preferred, 125 MHz or higher ideal)
|
||||
* SysTick not used by something else
|
||||
|
||||
## How it works
|
||||
|
@ -130,9 +130,9 @@ a high enough system clock frequency (≥80 MHz preferred, ≥125 MHz ideal).
|
|||
Dieharder isn't the most stringent test suite, though.
|
||||
[TestU01](http://simul.iro.umontreal.ca/testu01/tu01.html)'s BigCrush suite is
|
||||
much more comprehensive, but requires ***much*** more data (many gigabytes).
|
||||
Thanks to the limited throughput of a hardware TRNG, using this test isn't very
|
||||
Due to the limited throughput of a hardware TRNG, using this test isn't very
|
||||
feasible. Real evaluations such as FIPS 140-2, or Common Criteria EAL4 or
|
||||
higher, is completely out of my means.
|
||||
higher are completely out of my means.
|
||||
|
||||
In conclusion, don't trust someone's life --- neither your own nor someone
|
||||
else's --- with this. But otherwise, you should be fine. If you need the
|
||||
|
@ -264,7 +264,8 @@ Preparing to run test 209. ntuple = 0
|
|||
dab_monobit2| 12| 65000000| 1|0.71153312| PASSED
|
||||
```
|
||||
|
||||
At 48 MHz and a core voltage of 0.95 V, there would be three or four `WARN`ings.
|
||||
At 48 MHz and a core voltage of 0.95 V, there would be three or four `WARN`ings
|
||||
(but still no `FAILED` messages).
|
||||
|
||||
### Throughput
|
||||
|
||||
|
@ -289,9 +290,10 @@ very fast. The "cooked" (whitened) throughput is about 10 times higher than the
|
|||
would then modify the ROSC `COUNT` register in parallell. This is bad and
|
||||
will lead to bad results. Don't do this. (Or alternatively, add mutex guards,
|
||||
or bug me to do so.)
|
||||
* **More useful `rand()` functions**: currently, the code just gives you bits,
|
||||
and turning these bits into a random integer in a range, or a random float,
|
||||
..., is left as an exercise for the reader.
|
||||
* **More useful `rand()` functions**: currently, the code just gives you bits.
|
||||
Turning these bits into a random integer in a range, or a random float, ...,
|
||||
is currently left as an exercise for the reader. (Read: I totally forgot
|
||||
about these.)
|
||||
* **Protections against physical attacks**: if an adversary is in the physical
|
||||
proximity of the device, it's game over. They could attach an SWD debugger to
|
||||
the RP2040 (it has no protection against this), use a power side channel or
|
||||
|
@ -314,14 +316,14 @@ Here's a quick example:
|
|||
#include "rourand.h" /* 'cooked'/whitened rng */
|
||||
|
||||
|
||||
static void health_alarm(const char* msg) {
|
||||
static void health_alarm_callback(const char* msg) {
|
||||
// TRNG health alarm raised!
|
||||
iprintf("TRNG health alarm! %s\n", msg);
|
||||
}
|
||||
|
||||
int main() {
|
||||
/** raw randomness **/
|
||||
enum rourand_error r = rorand_init(health_alarm);
|
||||
enum rourand_error r = rorand_init(health_alarm_callback /* can be NULL */);
|
||||
if (r != rr_ok) {
|
||||
panic("rorand failed to initialize!");
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue