From 057f41dcd292bc4b47c8dfc36e98c59b34247b7d Mon Sep 17 00:00:00 2001 From: Triss Date: Thu, 24 Aug 2023 04:20:39 +0200 Subject: [PATCH] fix readme typos etc --- README.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 8ff84a5..b7f0920 100644 --- a/README.md +++ b/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!"); }