This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
We initially tested the CC2340R22(use sdk 8.10) for random number generation using the function int_fast16_t RNG_getRandomBits(RNG_Handle handle, void *randomBits, size_t randomBitsLength)
to retrieve random numbers, and found the quality to be lower than expected. After conducting the test four times with resets in between, we collected four sets of data, which showed deviations ranging from 20-30%.
Subsequently, we revised the relevant configuration files by replacing the current lrf_rfe_binary_ble5_cc23x0r5.c and rcl_settings_adc_noise.c files with those from the version 7.40 SDK. The results we obtained afterward indicated a marked improvement, yet there remains a considerable discrepancy.
This leads us to inquire about the following points:
Hi,
Thank you for reaching out.
As your results suggest, the RNG driver was updated in SDK 7.40 to improve the quality of the results obtained. You can reference the release notes of the CoreSDK of the same SDK version for more details: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/7.40.00.64/exports/docs/simplelink_mcu_sdk/release_notes_coresdk_lpf3_7_40_02_00.html
Focusing on the results you obtained with SDK 7.40 - The first element, I would like to point out, is that the data set considered remains fairly small, leading a small variation on the number of duplicates impacting a lot the deviation percentage. The second element I see is that, for the largest data set you actually have a pretty low deviation.
I am checking with my colleagues which details of our testing process can be shared online. To help sharing the right elements, would you like mentioning which other elements - despite the number of duplicates - you are checking in your tests?
Best regards,
I apologize for any confusion in my previous response. I've added some information to clarify: we are currently using SDK version 8.10, and its random number performance is not as good as the earlier 7.40 version. As shown above, there is still a deviation of more than 10% with a data volume of 800,000. In our current testing, we've simply added a while loop to generate hundreds of thousands of random numbers and print them out for comparison using formulas.
Hi,
Thank you for adding these details.
Can you confirm my understanding of your request?
Appreciate your help,
Best regards,
Hi,
I have two additional elements I would like to add to my previous answers:
I hope this will help,
Best regards,
Hi there,
Thank you for the additional information provided in your previous message.
rcl_settings_adc_noise.c
that you mentioned.Furthermore, I would be interested to learn about your internal testing and release procedures for the random number generation features in the SDK version 8.10. Ensuring that the RNG functions are reliable and secure is critical for our application, and understanding the testing protocols can provide us with additional confidence.
Looking forward to your insights.
Best regards,
Hi,
Detailed testing procedure cannot be shared on public forums. They are only provided under NDA as far as I am aware.
Thank you for your comprehension.
Best regards,
When using the same hardware and application code, the random numbers generated by the 8.10 SDK are not ideal. We have tried adjusting the size of RNGLPF3RF_noiseInputWordLen. What other possible solutions are there to improve the quality of the random numbers?
Hi,
The amount of noise collected should be large enough to ensure the entropy obtained is good enough. Based on the elements I have it seems the entropy level is ~ 1 bit entropy/ 1 bit noise.
In addition to the previous, one can run "health checks" on the entropy - for example the tests defined by NIST SP 800-90B. We are working on implementing these tests in the RNG driver. The updated driver will be release in a future SDK version.
I hope this will help,
Best regards,
Thank you for your insights and suggestions.
We have been utilizing TI's API to collect noise, and from my understanding, the noise should primarily influence the randomness of the initial seed rather than the quality of the random numbers generated subsequently. However, I acknowledge that there might be more nuances to this process that we are not currently accounting for.
To enhance the reliability of our current product, I would greatly appreciate if you could provide more detailed and actionable guidance. Specifically, we are looking for recommendations on best practices for noise collection, seed generation, and any other relevant aspects that could contribute to the overall quality and unpredictability of the random numbers produced by our system.
Looking forward to your expert advice.
Best regards
Hi,
Please note the CC2340R5 device does NOT offer a True Random Number Generator (TRNG). If the success of the product you are building depends on such TRNG, you should consider selecting other chipsets, such as the CC2642R or CC2640R2.
Best regards,
Dear TI Engineer,
Thank you for your prompt response. We are aware that the CC2340R5 device does not have a True Random Number Generator (TRNG) as you've mentioned. As stated in the manual, "The CC2340R device supports Random Number Generation (RNG) using on-chip analog noise as the non-deterministic noise source for the purpose of generating a seed for a cryptographically secure counter deterministic random bit generator (CTR-DRBG) that in turn is used to generate random numbers for keys, initialization vectors (IVs), and other random number requirements."
While we understand the internal logic and the RNG capabilities of the CC2340R5, we have encountered an issue that is not explained by the absence of a TRNG. Under the same testing conditions, the random number quality from the same chip was good when using the older version of the SDK. However, there is a noticeable degradation in quality when using the 8.10 SDK version. This discrepancy cannot be solely attributed to the lack of a TRNG on the chip.
We would appreciate if you could provide further insights or considerations regarding this issue. Are there any known changes in the RNG implementation between the SDK versions that could account for this difference? Or might there be other factors at play that we should be aware of?
Looking forward to your expert guidance on this matter.
Best regards,
Hi,
I am awaiting some feedback from the experts of this component.
To speed up the process, I would like to kindly request you to provide more details on the tests you are running. If possible, provide some code snippets so we can review those.
Appreciate your patience,
Best regards,
Thank you for your message. I appreciate your efforts in gathering feedback. To provide more context, my testing method involves initializing the random seed using RCL_AdcNoise_get_samples_blocking
and RNGLPF3RF_conditionNoiseToGenerateSeed
. Then, I initialize RNG with RNG_init
and continuously call Random_generateRandomBytes
in a while (1)
loop until I generate enough bytes. I will prepare the relevant code snippets and send them over shortly.
Thanks for your patience!
Best regards,
Hi,
Thanks!
One more element I would like to highlight here - The entropy used by the RNG originates from ambient noise. In theory this noise can be considered as white. In practice this noise is produced by physical sources that are not purely white. For this reason, if you take many samples from the RNG, you may see some elements to reproduce.
The intended way of using the RNG is to seed a software pseudo-random number generator - and then use the numbers generated by the software pseudo-random number generator.
The use I am describing is actually better practice as it reduces power consumption and provides faster responses.
Best regards,
Thank you for your insights. However, based on our testing under consistent external conditions, the issue should not be attributed to poor quality of the RF noise. Please encourage your technical team to verify the situation again.
I believe that my code only uses RF noise as the random seed, and the subsequent random numbers are generated by the software. Therefore, the quality of the RF noise should not affect the quality of the subsequent random numbers. If my understanding is incorrect, please feel free to correct me.