我需要arc4random_buf中数十亿个随机字节，而我的策略是一次请求X个随机字节，并重复多次。
我的问题是X应该多大。由于nbytes的{{1}}参数可以任意大，我想必须有某种内部循环，每次执行它的主体时都会产生一些熵。假设，如果X是每次迭代生成的随机字节数的倍数，则可以提高性能，因为我不会浪费任何熵。
我使用的是macOS，很遗憾，它是封闭源代码，因此我不能简单地阅读源代码。是否有任何便携式方法来确定最佳X？
答案 0 :(得分：2)
在典型的目标系统上进行一些基准测试可能是弄清楚这一点的最好方法，但是从几个实现的角度来看，缓冲区大小似乎不太可能对arc4random_buffer的成本产生很大的影响。
原始实现将arc4random_buffer实现为围绕生成一个字节的函数的简单循环。只要缓冲区足够大，可以避免过多的调用开销，则差异不大。
FreeBSD库实现似乎试图通过定期计算大约1K的随机字节来进行优化。然后arc4random_buffer使用memcpy将字节从内部缓冲区复制到用户缓冲区。
对于FreeBSD实现，最佳缓冲区大小将是内部缓冲区中可用的数据量，因为这样可以最大程度地减少对memcpy的调用次数。但是，无法知道有多少，并且由于密钥更新算法的原因，每次调用都不一样。
我的猜测是，在大于16K，甚至可能小于16K的缓冲区大小之间，您会发现差别很小。对于FreeBSD实施，如果您的缓冲区大小是8的倍数，则效率会稍微提高。
附录：我所知道的所有实现都有全局的密钥更新阈值，因此您不能通过更改arc4random_buffer中的缓冲区大小来影响密钥更新的成本。该库仅对生成的每X个字节重新生成密钥。