So I was researching how to solve this issue report (QNEthernet library): 0.35.0 causes crash on connect() (#105)
It turned out that entropy generation was causing a problem. The main difference in entropy use between 0.34.0 and 0.35.0 was that I assert if there's an entropy generation error when initializing a random key for secure TCP ISN (initial sequence number) calculation.
Tracing through, I found that, in short, lower frequencies were causing the TRNG entropy generation to fail. From some Google searching, it was suggested that the `TRNG_CONFIG_FREQUENCY_MAX` and `TRNG_CONFIG_FREQUENCY_MIN` values, but also the ring oscillator divisor, could be tuned. Not knowing much about optimal configuration values, I chose to play with the divisor. It can range from 0-3 and is a power of 2. I found that a value of `1` (divide-by-2) seems to work for 150MHz and a value of `2` (divide-by-4) seems to work for 24MHz. By "work", I mean no errors occur when generating or accessing the entropy bits.
I also didn't know much about what's best for which operating frequency, so I updated the library (commit 49b8f86f0) with a change that chooses a ring oscillator divisor value of `0` for F_CPU >= 528MHz and `2` otherwise.
The suggestion
Here's my suggestion: In order for proper entropy generation to occur, something must change for the lower operating frequencies. My change above could be a starting point.
A question
Here's a question for those that know: I did some entropy testing using the NIST test suite (about two years ago) and found that the current NXP SDK default TRNG values have worse entropy than the values used in the Entropy library. These current values are the same ones I use in my own TRNG code in the QNEthernet library, for this reason. Now, earlier versions of the NXP SDK, if I recall correctly when I was first exploring this, used default values that match the current Entropy library values. My best guess for why they changed the numbers is speed. The newer default configuration values (NXP SDK), I think, increase the entropy generation speed, but provide not-as-good entropy.
On to my question: Are the current Entropy library configuration values the way they are because that's what the NXP SDK used to have, or because those are suggested "better" values from some other information source?
Links
A relevant reference:
It turned out that entropy generation was causing a problem. The main difference in entropy use between 0.34.0 and 0.35.0 was that I assert if there's an entropy generation error when initializing a random key for secure TCP ISN (initial sequence number) calculation.
Tracing through, I found that, in short, lower frequencies were causing the TRNG entropy generation to fail. From some Google searching, it was suggested that the `TRNG_CONFIG_FREQUENCY_MAX` and `TRNG_CONFIG_FREQUENCY_MIN` values, but also the ring oscillator divisor, could be tuned. Not knowing much about optimal configuration values, I chose to play with the divisor. It can range from 0-3 and is a power of 2. I found that a value of `1` (divide-by-2) seems to work for 150MHz and a value of `2` (divide-by-4) seems to work for 24MHz. By "work", I mean no errors occur when generating or accessing the entropy bits.
I also didn't know much about what's best for which operating frequency, so I updated the library (commit 49b8f86f0) with a change that chooses a ring oscillator divisor value of `0` for F_CPU >= 528MHz and `2` otherwise.
The suggestion
Here's my suggestion: In order for proper entropy generation to occur, something must change for the lower operating frequencies. My change above could be a starting point.
A question
Here's a question for those that know: I did some entropy testing using the NIST test suite (about two years ago) and found that the current NXP SDK default TRNG values have worse entropy than the values used in the Entropy library. These current values are the same ones I use in my own TRNG code in the QNEthernet library, for this reason. Now, earlier versions of the NXP SDK, if I recall correctly when I was first exploring this, used default values that match the current Entropy library values. My best guess for why they changed the numbers is speed. The newer default configuration values (NXP SDK), I think, increase the entropy generation speed, but provide not-as-good entropy.
On to my question: Are the current Entropy library configuration values the way they are because that's what the NXP SDK used to have, or because those are suggested "better" values from some other information source?
Links
A relevant reference: