我是否应该基于其他方法生成密钥？这会以某种方式易于被利用吗？
#1 楼
简短的答案是肯定的。长答案也是。在现有技术下，/dev/urandom产生的数据与真正的随机性是无法区分的。获得比/dev/urandom提供的“更好”的随机性毫无意义，除非您使用的是少数“信息理论”加密算法之一，而这不是您的情况（您会知道的）。手册页因为
urandom有点令人误解，可以说是彻头彻尾的错误，因为它表明/dev/urandom可能“耗尽了熵”，应优先选择/dev/random； /dev/urandom可能由于低熵而暗示安全问题的唯一瞬间是在全新的，自动化的OS安装的最初时刻。如果机器启动到开始有一些网络活动的地步，那么它已经收集了足够的物理随机性，可以为所有实际使用提供足够高质量的随机性（我在这里谈论的是Linux；在FreeBSD上，瞬间的瞬间根本不会出现弱点）。另一方面，/dev/random倾向于在不适当的时间进行阻塞，从而导致非常实际和令人讨厌的可用性问题。或者，用更少的话说：使用/dev/urandom并感到高兴； （编辑：此网页非常清楚地解释了
/dev/random和/dev/random之间的区别。）出于产生“ cookie”的目的：例如cookie应当确保没有两个用户共享同一cookie，并且任何人都无法“猜测”现有cookie的值，因此在计算上是不可行的。假设使用适当质量的随机性（
/dev/urandom很好）并且足够长，则随机字节序列可以很好地完成此操作。根据经验，如果您的用户数少于2n（如果整个地球人口都可以使用您的系统，则n = 33），那么n + 128位的序列就足够了；您甚至不必检查是否存在与现有值的冲突：您一生中都不会看到它。 161位适合21个字节。如果您想使用较短的Cookie，并且仍然希望避免在数据库中查找冲突，则可以使用一些技巧。但这对于cookie几乎没有必要（我假设基于Web的上下文）。另外，请记住对Cookie保密（即使用HTTPS，并将Cookie设置为“ secure”和“ HttpOnly”标志）。
评论
关于urandom的“用尽”主题，您只是对的。在熵源（例如VM）差且熵使用率高（大量SSH连接，VPN隧道等）的系统上，urandom将返回较少的随机数据而不是阻塞。 “较少随机”是一个宽松的术语，但这意味着您更有可能看到重复。那是问题吗？在您的应用程序上很重要:)在这种情况下，urandom可能没问题。
–比尔·韦斯（Bill Weiss）
2011年5月26日14:40
@比尔，那是不正确的。由于大量使用熵，从/ dev / urandom看到重复的机会基本上为零。 （确切地说，“重复”是指统计上的重复次数明显高于偶然发生的次数。）从根本上讲，在您的一生中/ dev / urandom不会“用完”。
– D.W.
11年5月27日在6:20
您可能想观看30C3的J. Alex Halderman所做的演讲“快速Internet范围扫描及其安全应用程序”。他们对SSH密钥进行了较大的扫描，基本上发现了许多重复的密钥。事实证明，许多设备是嵌入式系统（例如路由器），缺少良好的熵源（鼠标，键盘等），通常会在启动后立即生成SSH密钥。他们确定对于/ dev / urandom，存在一个“熵间隙”，在系统启动后可能需要60秒（！），在此期间，输出实际上是可预测的。
–狗
2014年2月6日在22:05
@dog在CSPRNG被足够的熵播种之前，无论您读取多少数据，其输出始终是可预测的。一旦为它添加了足够的熵，无论您读取多少数据，它都将（实际上）不可预测。 “用尽熵”不是问题。 （CSPRNG确实在没有种子的情况下可以生成多少数据有理论上的限制，但是除非有问题的CSPRNG糟透了，否则您永远都不会打它们。）
–马特·诺德霍夫（Matt Nordhoff）
2014年4月19日在5:22
没有矛盾（而且，Schneier只是引用别人写的文章）。该研究论文担心从内部状态妥协中恢复，这种状态已经很糟了。如果您的系统完全遭到破坏，则应该将其从轨道上移开，而不是继续使用它来生成密钥。文章的意思是，如果您做错了事（继续按原样使用受感染的计算机并祈求最好），那么/ dev / random（和urandom）中使用的PRNG不会挽救您的皮肤-但实际上，没有任何东西。
–托马斯·波宁（Thomas Pornin）
2014年12月12日12:31
#2 楼
是的，这是一个很好的方法。@Thomas的解释很明确。而且他完全正确地批评了
/dev/urandom手册页。当场。，但是跳过“检查它是否已经存在”。那检查毫无意义。这不会发生。 （发生这种情况的可能性低于同一天被雷击多次的可能性。）
评论
那么谁是正确的，此页面还是schneier.com/blog/archives/2013/10/insecurities_in.html？
–起搏器
2014年12月12日上午10:25
@Pacerier，此注释中没有足够的空间来进行细微的解释。可以说该论文对这个问题的实际意义是非常有限的。参见例如mail-archive.com/cryptography@metzdowd.com/msg13301.html（关注技术内容）。另请参见mail-archive.com/cypherpunks%40cpunks.org/msg01390.html和mail-archive.com/cypherpunks%40cpunks.org/msg01365.html。如果您想更好地理解，请在Crypto.SE上询问另一个问题。请不要使用评论来提问；发表新问题。
– D.W.
2014-12-12 18:23
#3 楼
如果您使用的是Linux或NetBSD，请注意边缘情况。在Linux上，您需要确保启动后已获得足够的熵以正确播种CSPRNG，或使用
getrandom()系统调用，以从/dev/urandom读取数据，并且仅在极少数情况下阻塞，即在启动后没有足够的初始初始种子熵。在NetBSD中，您希望至少从
/dev/random读取一次，然后再从/dev/urandom读取数据在FreeBSD和MacOS上，
/dev/random和/dev/urandom之间没有区别。简短的答案仍然是使用
/dev/urandom。有关更多详细信息，请参见何时使用/ dev / random与/ dev / urandom。
#4 楼
来自http://www.linuxfromscratch.org/hints/downloads/files/entropy.txt“在计算机中生成真正的熵是相当困难的，因为量子物理学以外的任何事物都是随机的。 Linux内核使用具有加密算法（SHA1）的键盘，鼠标，
网络和磁盘活动
为/ dev / random设备生成数据。问题之一是
/>输入不是恒定的，因此内核熵池很容易变空。“
”使用键盘，鼠标，网络和光盘活动的另一个问题是
在空闲，无人值守和无盘系统几乎没有这种输入。“
对我来说，/ dev / urandom似乎很可能用完了，因为/ dev / random feeds它。
评论
你读过托马斯的答案了吗？如果是这样，您为什么认为这是错误的？
–基思·汤普森（Keith Thompson）
13年8月13日在22:29
Thomas的观点似乎是/ dev / urandom“用尽熵”不是问题。它继续通过其他方式生成随机字节，但实际上并不影响可预测性。我对这些问题的了解还不足以判断他是否正确（尽管他说的话与我在其他地方读到的内容一致）。您是否有特定的证据（或扎实的理论）表明耗尽熵池是/ dev / urandom的真正问题？实际预测/ dev / urandom输出结果比偶然结果更好的代码将是一个很好的证据。
–基思·汤普森（Keith Thompson）
13年8月15日在20:32
“ / dev / urandom使用来自/ dev / random的少量数据来播种辅助熵池。这具有扩大实际熵的效果，因此可以保存。使用/ dev / urandom可以导致/ dev / random的池变为空，但如果发生这种情况，/ dev / urandom将不会阻塞，并且将继续使用最后一个可用的种子，这使/ dev / urandom在理论上易于输出重复数据，具体取决于所用算法的限制，但这是极为罕见，据我所知从未发生过。
–台式电脑
13年8月20日在20:10
/ dev / urandom被广泛认为对所有加密目的都是安全的，但最偏执的人除外。”
–台式电脑
13年8月20日在20:11
您最近的评论似乎与您的答案相矛盾。
–基思·汤普森（Keith Thompson）
13年8月20日在20:20
评论
检查唯一性很慢。更好的选择是确保唯一性。尽可能将时间戳记附加到字符串。这将确保即使随机性相同，两个字符串也不会相同。@ DampeS8N您假设重复获取时间戳会产生单调递增的值。这远非事实：在快速的操作序列中，时间戳可以保持恒定，并且由于某种原因使时钟复位，因此时间戳可以倒退。 （推荐阅读：密码学工程第16章。）如果可以将计数器存储在非易失性存储器中，则它是一种确保唯一性的可靠（快速）方法。加密质量（P）RNG可以确保（加密质量）唯一性，无需其他技术。
@ DampeS8N如果/ dev / urandom重复了您的请求，那么您将遇到一个安全问题，即仅仅添加一个计数器将无法解决。随着我们的讨论逐渐远离这个问题，我建议我们继续进行信息安全聊天（chat.stackexchange.com/rooms/info/151）。
所有这些似乎都是学术性的。随机生成两个相同的1024位消息的可能性非常低，以至于甚至都没有考虑。
@Pacerier如果我们是宇宙中唯一的智慧生物，那么每次检查失败都会平均造成6e9 / 2 ^ 512 = 4.5e-145人死亡。这么小的数字甚至都没有一个SI后缀。我们应该专注于高风险的活动，例如在赢得彩票的那天跳伞时被晴朗的天空击中。