出于最能描述为哲学的原因，我想知道以下内容。假设我要在时间 X 读取 /dev/random （或 /dev/urandom）。在一种情况下我只是这样做，但在另一种情况下，当 /dev/random 处于相同状态时，我推送一些字节数在时间 X 之前进入 /dev/urandom。输出是否相同？忽略这样的情况：由于巨大的、反常的巧合，我写入的特定字节发生使 /dev/random 的状态保持与之前相同的状态。
另一种询问方式：是否写入 /dev/random立即地改变（除非不太可能的巧合） /dev/random 的状态，或者是否存在某种缓冲（输入或输出）意味着 /dev/random 将受到我的写入的影响，但仅限于可能遥远的未来？
注意：我没有使用 ioctl 来声明在编写时可以获得额外的熵。
我想强调的是，这不是一个“重要”的问题，据我所知，我完全理解，某些量子随机性硬件可能会因为世界各地的某人打哈欠或不打哈欠而改变状态，更不用说我是否打哈欠了。不要写。这个问题严格来说是关于写入 /dev/random 的行为是否会立即改变软件的状态，或者 /dev/random 是否已缓冲您接下来要得到的内容（或缓冲您写入它的内容，直到它决定重新播种一些东西），因此写入的效果被延迟。
既然这个问题显然是不合时宜的，那么让我解释一下我为什么要问。我运行一个游戏，其中 /dev/random 的输出用于决定游戏结果。在游戏过程中，人们正在咕哝地说话，我会实时复制该音频流，对其进行哈希处理，然后将其推送到 /dev/random 中。我想要决定的是，我是否可以准确但荒谬地宣称，“如果你不这么说，你就不会掷出 1”，或者我是否应该只提出较弱的主张“你所说的”有一天它会回来困扰你的骰子。”
同样有趣的是，“现在影响它”可能是 /dev/random 的永久属性，还是只是当前实现的侥幸。
谢谢！
答案1
（假设 drivers/char/random.c 中的文档是正确的，）您编写的任何内容都会直接混合到熵池中，并且随机输出是该池的哈希值。所以改变应该是立即的。
但是，读取 /dev/random 可能会阻塞（当熵为空时），写入（使用 poll）也可能会阻塞（当熵已满时），并且写入 /dev/random 通常可能非常慢。所以这个想法有一些性能方面的考虑。
如果您希望随机数据取决于用户的抱怨，您可以完全跳过 /dev/random 并通过您自己的 SHA 函数滚动所有内容。这也将使您能够完全控制国家。因此，您可以为每个用户提供自己的哈希实例，以便他们的随机数完全基于他们自己的声音。不依赖于系统随机性，也不依赖于其他人说什么。如果他们了解您的哈希函数实现并发送准备好的音频模式，这也可能让他们作弊。 ;-)
但除此之外，整个想法相当深奥。随机数据是不可预测的，哈希结果也是如此；除非你不希望它是随机的，否则仅仅读取/dev/_u_random而不写回任何东西就没有多大意义。