[参考译文] CC2340R5：CC2340R22的 RNG 质量和 SDK 测试方法

您好！  

感谢您联系我们。  

正如您的结果所示、RNG 驱动程序已在 SDK 7.40中更新、以提高所获得结果的质量。 有关更多详细信息、请参阅同一 SDK 版本的 CoreSDK 的版本说明： 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 

重点关注您使用 SDK 7.40获得的结果-我想指出的第一个要素是、所考虑的数据集仍然相当小、导致重复数量的差异很小、从而对偏差百分比产生很大影响。 我看到的第二个因素是、对于最大的数据集、实际上具有相当低的偏差。  

我正在与我的同事核实我们的测试流程的哪些详细信息可以在线分享。 为了帮助共享正确的元素、您是否想提及您在测试中检查哪些其他元素(尽管存在大量重复项)？

此致、  

对于我之前的答复中出现的任何混淆、我深表歉意。 我添加了一些信息来澄清：我们目前使用的是 SDK 8.10版、其随机数性能不如之前的7.40版。 如上所示、数据量为800,000时、偏差仍超过10%。 在我们当前的测试中、我们只添加了一个 while 循环、可生成数十万个随机数、并使用公式打印出来进行比较。

您好！  

感谢您添加这些详细信息。  

您能否确认 我对您的请求的理解？

• 在 SDK 7.40上、RNG 行为正常
• 在 SDK 8.10上、RNG 行为不正确

感谢您的帮助、

此致、  

有

你(们)好、

感谢您在之前的消息中提供的其他信息。

1. 我们实际上正在利用 ADC 作为熵源、 rcl_settings_adc_noise.c 您在前面提到的噪声相关文件中也提到了这一点。
2. 我还查看了 SysConfig 生成的代码、并注意到它与我们当前的代码逻辑一致。 然而、我想知道我们是否可以考虑任何替代办法或解决办法。

此外、我希望了解 SDK 8.10版中随机数生成特性的内部测试和发布过程。 确保 RNG 功能可靠且安全对于我们的应用至关重要、了解测试协议可以让我们更加放心。

期待您的见解。

此致、

您好！  

详细的测试程序不能在公共论坛上共享。 据我所知、这些内容仅根据保密协议提供。  

感谢您的理解。

此致、  

当使用相同的硬件和应用程序代码时、8.10 SDK 生成的随机数并不理想。 我们已经尝试调整 RNGLPF3RF_noiseInputWordLen 的大小。 还有哪些其他可能的解决方案可以提高随机数的质量？

您好！  

收集的噪声量应足够大、以确保获得的熵足够好。 根据我所拥有的元素 、熵水平似乎为~ 1位熵/ 1位噪声。  

除了前面的,  可以对熵运行"健康检查"-例如  NIST SP 800-90B 定义的测试。 我们正在努力在 RNG 驱动程序中实现这些测试。 更新的驱动程序将在未来的 SDK 版本中发布。  

我希望这将有所帮助、

此致、  

感谢您提供宝贵的意见和建议。

我们一直在利用 TI 的 API 来收集噪声、根据我的理解、噪声应该主要影响初始种子的随机性、而不是随后生成的随机数的质量。 但是、我承认、这一进程可能有更多的细微差别、而我们目前还没有考虑这些细微差别。

为了提高我们当前产品的可靠性、如果您能提供更详细和可行的指导、我将不胜感激。 具体而言、我们正在寻找有关噪声收集、种子生成以及任何其他可能导致系统产生的随机数的整体质量和不可预测性的相关方面的最佳实践建议。

期待您的专家意见。

此致

尊敬的 TI 工程师：

感谢您的及时响应。 我们知道 CC2340R5器件没有您提到的真随机数发生器(TRNG)。 如手册中所述、"CC2340R 器件支持使用片上模拟噪声作为非确定性噪声源的随机数生成(RNG)、以生成加密安全计数器确定性随机位发生器(IV-DRBG)的种子、而 RNG 用于为密钥、初始化向量(CTR)和其他随机数要求生成随机数。"

虽然我们了解 CC2340R5的内部逻辑和 RNG 功能、但我们遇到了一个没有 TRNG 无法解释的问题。 在相同的测试条件下、使用旧版本的 SDK 时、同一芯片的随机数质量良好。 但是、使用8.10 SDK 版本时、质量会明显下降。 这种差异不能完全归因于芯片上缺少 TRNG。

如果您能就此问题提供进一步的见解或考虑、我们将不胜感激。 SDK 版本之间的 RNG 实现中是否有任何已知的更改可以解释这种差异？ 或者是否还有我们应该知道的其他影响因素？

期待您对此问题的专家指导。

此致、

您好！

我正在等待该部分专家的一些反馈意见。
为了加快该过程、请您提供有关您正在运行的测试的更多详细信息。 如有可能、请提供一些代码片段、以便我们查看这些代码片段。  

感谢您的耐心、

此致、  

感谢您的留言。 感谢您在收集反馈方面所做的努力。 为了提供更多的上下文,我的测试方法涉及使用RCL_AdcNoise_get_samples_blocking和初始化随机种子RNGLPF3RF_conditionNoiseToGenerateSeed。 然后、我使用初始化 RNGRNG_init、并连续Random_generateRandomByteswhile (1)循环调用、直到我生成足够的字节。 我将准备相关的代码片段并尽快发送出去。

感谢您的耐心等待！

此致、

您好！  

谢谢！

我想在这里强调另一个元素：RNG 使用的熵源自环境噪声。 理论上、该噪声可视为 白噪声。 在实践中、这种噪声是由并非纯 白的物理来源产生的。 因此、如果您从 RNG 中提取许多样本、您可能会看到一些要重现的元素。  
使用 RNG 的预期方法是种子软件伪随机数生成器-然后使用 软件伪随机数生成器生成的数字。  
我所说的用法实际上是更好的做法、因为它可以降低功耗并提供更快的响应。  

此致、  

感谢您的宝贵意见。 不过、根据我们在一致外部条件下进行的测试、该问题不应归因于射频噪声质量不佳。 请鼓励您的技术团队再次验证该情况。

我认为我的代码仅使用射频噪声作为随机种子、后续随机数由软件生成。 因此、射频噪声的质量不应影响随后随机数的质量。 如果我的理解有误、请随时纠正。