一些小伙子说：

任何试图通过确定性方法生成随机数的人当然都处于犯罪状态。

这总是意味着您不能仅凭计算机生成真正的随机数。他说，当计算机的大小与单个Intel 8080微处理器（约6000个阀）的大小相同时。计算机变得越来越复杂，我相信冯·冯·诺依曼的说法可能不再正确。考虑到仅软件实现的算法是不可能的。它们在物理硬件上运行。真正的随机数生成器及其熵源也由硬件组成。

这个Java片段陷入了循环：

      file.writeByte((byte) (System.nanoTime() & 0xff));

可以创建一个我以图像表示的数据文件：

您可以看到结构，但也有很多随机性。有趣的是，此PNG文件的大小为232KB，但包含250,000灰度像素。PNG压缩级别最高。那只是7％的压缩率。相当不可压缩。有趣的是该文件是唯一的。此文件的每一代都是略有不同的模式，并且具有相似的〜7％压缩率。 我强调这一点，因为这对我的论点至关重要。熵约为7位/字节。当然，使用更强大的压缩算法将减少这种情况。但不要减少到0位/字节附近。通过拍摄上面的图像并将其颜色映射表替换为随机的图像，可以产生更好的印象：

大多数结构（在上半部分）消失了，因为它只是具有相似但略有不同值的序列。这是仅通过在多任务操作系统上执行Java程序而创建的真正的熵源吗？不是统一分布的随机数生成器，而是一个的熵源？由在物理硬件上运行的软件构建的熵源，恰好是PC。

补充性

为了确认每个图像都产生新的熵，而没有所有人共有的固定模式，生成了10个连续图像。然后将它们连接起来，并使用我可以编译的最强大的存档器（paq8px）进行压缩。此过程将消除所有通用数据，包括自动关联，仅保留更改/熵。

串联文件被压缩到〜66％，这导致〜5.3位/字节或10.5Mbits /图像的熵率。令人惊讶的熵$\smile$

补充2

有负面评论认为我的压缩测试方法的熵是有缺陷的，仅给出了一个松散的上限估计。因此，现在我通过NIST的官方加密熵评估测试SP800-90B_EntropyAssessment运行了级联文件。这与非IID熵测量一样好。这是报告（很抱歉，这个问题越来越长，但是问题很复杂）：-

Running non-IID tests...

Entropic statistic estimates:
Most Common Value Estimate = 7.88411
Collision Test Estimate = 6.44961
Markov Test Estimate = 5.61735
Compression Test Estimate = 6.65691
t-Tuple Test Estimate = 7.40114
Longest Reapeated Substring Test Estimate = 8.00305

Predictor estimates:
Multi Most Common in Window (MultiMCW) Test: 100% complete
    Correct: 3816
    P_avg (global): 0.00397508
    P_run (local): 0.00216675
Multi Most Common in Window (Multi MCW) Test = 7.9748
Lag 

Test: 100% complete
    Correct: 3974
    P_avg (global): 0.00413607
    P_run (local): 0.00216675
Lag Prediction Test = 7.91752
MultiMMC Test: 100% complete
    Correct: 3913
    P_avg (global): 0.00407383
    P_run (local): 0.00216675
Multi Markov Model with Counting (MultiMMC) Prediction Test = 7.9394
LZ78Y Test: 99% complete
    Correct: 3866
    P_avg (global): 0.00402593
    P_run (local): 0.00216675
LZ78Y Prediction Test = 7.95646
Min Entropy: 5.61735

结果是NIST相信我已经产生了5.6位/字节的熵。我的DIY压缩估算结果为5.3位/字节，稍微保守一些。

->证据似乎支持这样一种观点，即仅运行软件的计算机就可以产生真实的熵。冯·诺依曼（Ver Neumann）错了（但也许对他的时间来说是正确的）。

我提供以下可能支持我的主张的参考：

程序执行速度中是否存在不确定性的随机模型？

概率硬实时系统的WCET分析

是否存在可以生成非确定性混沌模式的软件算法？以及混沌效应的相关性。

与量子熵不确定性原理平行

AlekseyShipilёv 关于nanoTime（）的混沌行为的博客条目。他的散点图和我的没什么不同。

仅仅因为您看不到模式并不意味着就不存在任何模式。仅仅因为压缩算法找不到模式，并不表示不存在任何模式。压缩算法不是可以神奇地测量源的真实熵的灵丹妙药。它们给您的只是熵的上限。（类似地，NIST测试也只给您一个上限。）混沌不是随机性。

需要进行更详细的分析和检查才能开始对以这种方式获得的随机性质量有所信心。

有是有理由认为，我们或许可以通过利用时钟抖动和随机获得一定量的两个硬件时钟之间的漂移，但它的细腻和棘手，所以你必须要小心。我不建议尝试自己实施。相反，我建议您使用高质量的熵源（通常在大多数现代操作系统中实现）。有关更多详细信息，另请参见 Wikipedia，Haveged和/crypto//q/48302/351（似乎您已经知道）。

最后，对您的开瓶器发表评论：

“任何试图通过确定性手段产生随机数的人当然都处于犯罪状态。”

这总是意味着您不能仅凭计算机生成真正的随机数。

不，这不是通常的用法，也不是它在说什么。就是说，您无法通过确定性方法生成真正的随机数。是否可以在计算机上执行此操作取决于计算机是否具有确定性。如果计算机是确定性的，或者您的程序仅使用确定性的操作，则不能。但是，许多计算机包含不确定性元素，如果程序使用它们，则需要更详细的分析，然后才能决定是否可以使用它们来生成随机数。在您的情况下nanoTime()是不确定的。

如果您使用的是熵/随机性的某种硬件资源，那么您就不会“试图通过确定性的方法来产生随机性”（我强调）。如果您没有使用任何熵/随机性的硬件来源，那么功能更强大的计算机仅意味着您每秒可以犯下更多的罪过。

我一直都理解引号是指确定性算法具有固定量的熵，尽管输出看起来可能是“随机的”，但它所包含的熵不能超过输入所提供的熵。从这个角度来看，我们看到您的算法通过以下方式走私了熵System.nanoTime()-大多数“确定性”算法的定义将不允许调用此函数。

报价虽然精妙，但实际上是一种重言式。没有什么可以反驳的，也没有可能使它不再成立的硬件发展。这与硬件无关，而与确定性算法的定义有关。他只是观察到确定性和随机性是不相容的。对于任何确定性算法，其整个行为都由其起始条件来预测。如果您认为已发现异常，那么您会误解确定性的含义。

的确，在具有一系列复杂缓存的共享计算机上运行并接收各种网络和硬件输入的进程比在简单，隔离，专用硬件上运行的进程具有更多的熵。但是，如果该过程访问了熵，那么它将不再是确定性的，因此引用不适用。

任何试图通过确定性方法生成随机数的人当然都处于犯罪状态。

当您将“生活在一种犯罪状态”解释为“胡说八道”时，那是完全正确的。

您所做的是使用相当慢的方法System.nanoTime()来生成相当弱的随机性。你测量了一些

熵速率约为5.3位/字节

但这只是上限。您所能获得的只是一个上限。实际熵可以小几个数量级。

尝试改用MD5之类的加密哈希填充数组。计算一个类似的序列md5(0), md5(1), ...（从每个值取一个或多个字节，这无关紧要）。您根本不会获得任何压缩（是的，MD5已损坏，但仍然足以产生不可压缩的数据）。

可以说，根本没有熵，但是您要测量8位/字节。

当您确实需要随机的东西时，不仅必须使用硬件源，还必须知道它实际产生多少熵的确定的下限。虽然最有可能是随机的nanoTime()，但我没有意识到其上有任何非平凡的下限。

当您需要加密的随机性时，您实际上必须诉诸于您的操作系统，您的语言或良好的库提供的功能。这样的提供者从多个来源和/或专用硬件收集熵，并且相当多的工作已经投入到这种熵估计中。

请注意，您通常几乎不需要任何熵。用几个随机字节初始化的良好（确定性）PRNG可用于加密，因此也可用于其他所有内容。

我以为我会喜欢“随机”的含义。与确定性过程的输出相比，这里的大多数答案都在谈论随机过程的输出。那是“随机”的一个很好的含义，但这并不是唯一的含义。

随机过程输出的一个问题是它们很难与确定性过程的输出区分开：它们不包含有关其来源随机性的“记录”。一个极端的例子是著名的XKCD漫画，其中随机数生成器总是返回4，代码注释声称它是随机的，因为它来自冲模。

定义“随机性”的另一种方法称为Kolmogorov复杂度，它基于数据本身，而不管它是如何生成的。某些数据（例如，数字序列）的Kolmogorov复杂度是输出该数据的最短计算机程序的长度：如果数据具有较高的Kolmogorov复杂度，则数据“更随机”。

您使用PNG等压缩算法并比较压缩前后的长度，类似于Kolmogorov复杂度的想法。但是，Kolmogorov的复杂性允许以任何图灵完备的编程语言将数据编码为程序，而不是像PNG这样的有限格式。通过运行它们来“解压缩”此类编码（程序），这可能会花费任意时间和内存（例如，超过我们微不足道的世界中可用的时间和内存）。

赖斯定理告诉我们，总的来说，我们无法区分永远循环的程序和输出数据的程序。因此，很难找到某些数据的Kolmogorov复杂度：如果我们记下一个生成该数据的程序，实际上可能会有一个较短的程序（即较低的复杂度），但是我们没有发现它，因为我们无法从无限循环中区分出来。Kolmogorov的复杂度因此是无可争议的，尽管如果我们知道Busy-Beaver数，我们可以通过使用它们来约束检查每个程序的时间来计算它。

对于您的示例数据，要找到其Kolmogorov复杂度（即“固有随机性”），我们需要找到输出相同字节序列并取其长度的最短确定性程序。

现在我们可以从Kolmogorov复杂度的角度回答您的问题，并且我们发现报价是正确的：我们无法通过确定性方法生成随机数（高Kolmogorov复杂度）。

为什么不？假设我们编写了一个小型计算机程序，并用它生成了一个随机数序列。以下情况之一必须适用：

• 我们产生了大量的输出。但是，由于我们知道此输出是由一个小程序生成的，因此该输出（根据定义）具有较低的Kolmogorov复杂度，因此在这种意义上并不是“随机的”。
• 我们生成的数字太少，以至于全部记下来与记下简短的生成程序所需的位数相同甚至更少。在这种情况下，数字是不可压缩的，这表明它们在Kolmogorov意义上是相当随机的。然而，由于输出量相当于我们把在（该程序的源代码），它是公平地说，该计划并没有“生成”的随机性，我们选择了该程序。毕竟，在这种情况下，我们的生成程序也可能只是这些确切数字的列表（例如print([...])）。

在这两种情况下，我们所生成的随机性都不会比我们所输入的（生成程序源代码的“随机性”）更多。我们可能会尝试通过使用更长的生成程序来解决此问题，以避免输出的生成器很短，但是只有两种方法可以做到这一点：

• 以某种方式系统地“膨胀”代码。但是，Kolmogorov复杂性并不关心我们用来生成数据的特定程序：它只关心哪个最小的生成程序。系统膨胀不会增加Kolmogorov的复杂性，因为代码中的这种模式本身可以用很少量的代码生成。例如，如果我们采取run(shortGenerator)并添加整个系统膨胀的负载来获得run(bloatedGenerator)，则仍然存在形式较短的生成器run(addBloat(shortGenerator))。
• 非系统地添加膨胀，即不添加任何模式，以便addBloat函数最终不得不像代码本身一样膨胀。但是，缺少模式正是使某些事物随机化的原因（高Kolmogorov复杂性）。因此，以这种方式使生成程序膨胀会增加输出的随机性（Kolmogorov复杂度），但同时也会增加我们必须以源代码形式提供的随机性（Kolmogorov复杂度）。因此，提供“随机性”而不是程序的仍然是我们。在上面仅写的示例中print([...])，添加非系统膨胀等同于在该硬编码列表中仅写更多“随机”数字。

压缩不是对随机性的精确测试，也不是看着图像并说“看起来随机”。

随机性通过经验方法进行检验。实际上，存在用于测试随机性的专门设计的软件/算法套件，例如TestU01和Diehard测试。

此外，您的图片实际上是一维数字字符串，映射到一个空间上，因此不能很好地表示某些可能出现的图案。

如果要逐像素检查图像，则很可能会发现许多短暂增加价值的短图案，然后突然下降。如果要创建一个图，其中x值为样本数，y值为从“随机”函数获得的值，则您很可能会发现您的数据实际上看起来像锯齿波：

这是由在模块化算术下（您的计算是一个示例：时间以接近恒定的速率增加，并且& 0xFF作为mod 256）增加的值所构成的模式。

您将随机数的概念与“看起来是随机的数”混淆了。

要了解冯·诺依曼的报价，我们必须了解“生成随机数”的含义。 Warbo的答案链接非常好为此提供 XKCD：

当我们谈论随机数时，我们并不是在谈论值本身。显然，4不会比3随机。随机数是不可预测的。有时我们会为此添加条件。如果攻击者不知道种子/密钥，那么密码安全的伪随机数生成器（CSPRNG）会生成比随机机会更好的预测数字，但是如果我们谈论的是真正的随机数（不是伪随机数），通常将其定义为即使在具有完整系统知识（包括任何键）的情况下也无法预测的数字。

现在，正如许多人指出的那样，您的示例不是确定性的。程序未指定从中产生什么值System.nanoTime()。因此，它与使用CSPRNG生成伪随机数的类别不同。如果密钥的值是确定性的，则前者可能是不确定性的，而后者可能是确定性的。前者包含未定义为具有确定性值的操作。

但是，您会注意到我说过这可能是不确定的。请注意，这System.nanoTime()并非旨在为此目的提供价值。它可能不确定也可能不确定。应用程序可能会调整系统时钟，以使System.nanoTime()所有调用均以256纳秒（或接近）的倍数发生。或者您可能正在使用Javascript工作，在此Java中Spectre的最新利用导致主要浏览器有意降低其计时器的分辨率。在这些情况下，您的“随机数”可能会在您未计划的环境中变得高度可预测。

• 因此，生成具有确定性过程的随机数...罪过。
• 使用专用的随机硬件生成随机数...不是罪过。
• 用计算机的不确定性生成随机数...也许是罪过。

这完全取决于您的打算。如果您正在加密发送给海绵宝宝的情书，以使您的妹妹无法阅读它们，那么对您的所谓随机数的要求就非常低。 System.nanoTime()照常使用可能就足够了。如果您正在针对正在积极寻求核武器的先进外国提供保护，则您可能需要考虑使用旨在应对挑战的硬件。

我认为您不理解该要求。关键是，如果有一个确定性的过程可以生成一个“随机”数字序列（或其他任何东西，实际上），那么找到模式仅仅是找到该过程的任务！

因此，总是存在确定性的方法来预测下一个整数。如果我们假设随机性，这正是我们所不希望发生的事情！

任何足够复杂的确定性都不能与随机性区分开。

-从Wrzlprmft的用户页面

因此，即使某些事物看起来是随机的，但如果我们有确定的生成过程，为什么在地球上我们仍将其建模为“随机”呢？

我认为这是关键问题。您只显示了某种形式的不可区分性了PRNG的性和“真正的随机性”。

然而，这些概念因此是平等的并不成立。特别地，随机性是数学的理论概念。上面我们已经证明，从理论上讲，将PRNG视为“真正的随机性”会导致矛盾。因此，它们不能相等。

我认为其他人已经指出了这一点，但并不是要强调，所以让我也增加讨论。

正如其他人已经指出的那样，存在测量熵的问题。压缩算法可能会告诉您一些信息，但是它们与源无关。既然您对数据的生成方式有了更多的了解，就可以构造一个更好的算法来压​​缩它，这意味着真实的熵要低得多。

此外，您在某种程度上误解了“在计算机上”和“确定性”这两个短语的含义。您当然可以执行不确定性在计算机上操作。

此外，事实上，您只是做到了，但是乍一看没有那么明显。

典型的确定性用于随机数生成的算法为。PRNG像线性同余生成器。他们是有状态的。内部状态意味着较少的熵，因为下一个状态由上一个确定。我不会深入探讨，这对您来说很明显。重要的一点是，完全确定性算法仅取决于先前的状态，无论状态如何。

现在看看您的算法。它基于什么？你有多少状态？它是确定性的吗？

  file.writeByte((byte) (System.nanoTime() & 0xff));

让我们忽略file.write刷新缓冲区，等待I / O的任何问题（您是否试图在硬盘驱动器电缆上添加一会儿大噪声？不？嘿，您可以这样做。嘿，那是不确定的！:)），以及让我们专注于源头，它更重要。

该时间是某种状态的。它有所不同，但大多数是相同的。这就是为什么您试图绕过它并使用＆0xFF删除大部分状态的原因。但是您还没有全部删除，上一个读取的某些状态可能会泄漏到下一个，所以肯定不是完全不确定的*）

但是我们对此不感兴趣。为了“证明”引用是错误的：

任何试图通过确定性方法生成随机数的人当然都处于犯罪状态。

您需要通过确定性的方法进行证明。
我们感兴趣的是：您的算法肯定是完全确定性的吗？

..显然不是。

  System.nanoTime() & 0xff

那是时间测量。时间和测量。如果值被缓存，则测量部分可以使其具有确定性。我认为不是，否则此功能将没有意义。然后，如果从源头上即时读取它，则我们具有基于时间的价值。由于（我再次假设）您没有在单任务专用硬件上运行它，因此有时可能需要上下文切换。即使您具有单任务专用硬件，由于时间源中的温度/湿度漂移，总线时钟时间等，时间测量仍可能不确定。

我完全同意我在这里很生气。漂移不会太大以至于不会产生太大的影响（尽管实际上nanotime可能会很大）。更重要的nanotime是，它意味着要快。它不是从实时源读取的。它基于处理器的内部指令/周期数。如果您确保没有上下文切换，那实际上是确定性的。

我的观点是，如果您基于时间来运行真正的100％确定性算法实际上可能非常困难，并且除非您确实具有完全确定性的手段，否则您无权反驳该报价。

*）有趣的是，如果您采用硬核方式，则可能会增加实际的随机性。逐位执行＆0x01，并在读取每一位之前使线程等待明显的时间。以这种方式生成数据的时间太长了，但是我实际上认为它可以认为是几乎完全随机的，如果您在非RTOS上运行，并且在每个“明显的时间”内IFF足够高，以确保操作系统要么进入睡眠状态，要么上下文切换到另一个任务。

我认为您需要的答案以您自己在回复另一个答案时发表的评论开头：

这种模式是Java，JVM，OS，CPU +高速缓存，硬盘，我正在流式传输的Trance音乐之间相互影响的结果，这消耗了CPU / RAM周期以及两者之间的所有内容。该模式仅来自for / next循环内的一行Java代码。熵的很大一部分来自基础硬件电路。

我想您已经意识到了这一点：您没有使用确定性的方法来创建模式。

您使用了一台计算机，其中不可忽略的一部分是确定性的，但是熵来自外部不确定性（或至少对于当前所有实际意图和目的都是不确定性）来源：您或外部世界在相互作用与计算机（在较小程度上，计算机硬件中可能影响事物计时的任何物理缺陷）。

顺便说一下，这是现代操作系统如何播种可用于程序的随机数生成器的重要组成部分：通过利用熵与其硬件和用户进行交互，我们希望攻击者无法预料。

顺便说一句，迄今为止，外部世界的熵实际上是一个必须以其他方式良好编码的密码术解决的问题：具有可预测行为的计算机在启动时和运行时，例如具有只读存储或从网络启动且具有可预测的网络环境的那些（未连接到网络或网络上的工作负载非常低，以至于所有内容都可以在内部交付）时间（可靠的时间），并且运行具有相同行为的有限软件集，可能会严重高估他们从这些假定为不可预测的组件中获得的熵，最终生成更多可预测的数而不是在典型的工作站上为您做各种其他事情（在后台播放音乐，与Dropbox同步等）。

我认为大多数答案都集中在检查循环中以纳秒为单位的时间测量的最后八位是否是收集该熵的好方法。在您将示例中的方法用作实践中的随机数生成方案之前，这是一个非常重要的问题，需要正确回答，但这是与我想问的问题不同的问题。

为了增加以前的答案，这是思考此问题的简便方法。

这都是关于随机性和确定性的区别。之后，我们将去拜访冯·诺依曼。

随机数

真正的随机数生成器将没有模式，甚至不会隐藏在背景中，到目前为止，我们可以使用该模式来预测下一个数字。在理想的世界中，您可以了解物理宇宙以及有关系统的所有知识，每纳秒几纳秒，而尝试预测下一个产生的数字仍然无济于事。

这是一个理想的情况-实际上，我们通过将许多“不差近似”或“真正随机”的源混合在一起而达到目标，或者通过数学方式将它们混合得足够多，以至于您可以从数学上证明它们非常难以处理且对任何特定的数字或模式缺乏偏见。

• “良好”源类似于等待放射性衰变过程或其他本来无法预测的量子过程。来自热敏半导体的输出。二极管或其他电气材料中的随机噪声。计数来自太阳的光子。

• 混入其中，我们还可以添加一些我们认为“不错”的东西，这对他们没有任何帮助，因此会有所帮助：等待下一个鼠标单击或网络数据包。下一个文件写入时的最后时间。“已知但数学上相当随机的”伪随机数生成器函数的输出。先前使用随机数得出的先前熵。

这里的目的是要获得一个仍然无法预测的数字，无论您在宇宙中知道什么，并且是统计学上可能是这个作为，没有数学上检测到的图样，偏见或可预测性，以及对事件没有关联可以被监视并用于预测。（或者，如果与某个事件相关联，那么它的连接方式将变得非常脆弱，例如“仅在上次单击鼠标时显示纳秒数字”）

确定性数

数学家可以证明有关公式和函数的事物。因此，有可能证明一个函数在重复调用时不会给任何模式带来任何偏差或偏好，除了简单的模式“如果重复调用，这些就是该函数的输出”。

因此，例如，如果您选择一个介于1到1千万之间的数字，将其写成二进制，然后反复“哈希”它，那么您将获得一个看起来非常随机的数字序列。它几乎是随机的-但实际上根本不是随机的。您可以预测给定的算法和任何状态，下一个数字将是什么。

我们称其为“伪随机”，因为它看起来并且似乎主要是随机的，即使不是。

这是一个很好的例子。考虑一下由3位“随机数”组成的序列：983、367、336、244、0665、664、308、602、139、494、639、522、473、719、070、217。假设我告诉你我可以用相同的方式生成一百万个数字。然后，您可以交给统计学家，统计学家将确认（说）它们的分布均匀或分布均匀。没有明显的可预测模式b。他们看起来很随意吧？但是现在我告诉你，他们实际上是

Pi的第500位数字，以3s分组。

突然，但是随机

Pi的位数

可能是，您可以立即预测接下来的2个数字将是986和094。

明确地说，我不知道

Pi的位数

是。将进行研究，其答案众所周知。但是关键是：原则上，对于确定性过程之后产生的任何来源，同样的结论是正确的。

在两者之间

在这两者之间，是“看似随机并且通常在某种程度上通常是随机的事物”的整个范围。一个人可以混入的随机性和接近随机性越多，输出就越难于在数学上检测到任何模式或预测任何输出。

回到冯·诺伊曼和您的问题

如您所见，确定性输出可能看起来是随机的，但甚至可能在统计上是随机分布的。他们甚至可能使用我们没有现实希望知道的“秘密”或快速变化的数据。但是，只要是确定性的，这些数字仍然永远不会真正是随机的。它们只能“足够接近随机以至于我们很高兴忘记差异”。

那就是你给的报价的意思。确定性过程不能给出随机数。它只能给出看起来像并且表现得很像随机数的数字。

现在，我们可以这样重新表述您的问题：“我（或任何现代）计算机的输出可以看起来和完全随机地运行，这是否意味着冯·诺伊曼的报价现在已经过时且不正确？”

问题仍然是：即使您计算机的输出可能看起来和行为随机，也可能不是真正随机的。如果仅是确定性地计算，则意味着没有任何关于下一个数字gettinbg的不可预测的因果关系（从这个意义上讲，“确定性”意味着什么）。我们从一些现有的数据（已知的）开始，应用一个已知的过程（复杂的或混乱的或类似的东西），然后我们得到一个看起来像新的“随机数”的东西。但这不是随机的，因为该过程是确定性的。

如果您说您的方法将包括一个真正的硬件随机数发生器以解决该问题（例如由放射性衰变或半导体噪声产生的随机数），那么您的答案现在可能是随机的-但根据定义，您的方法不再是确定性的，正是因为您无法再根据输入/初始数据（原因）来预测输出（或效果）。

冯·诺依曼几乎赢得了双赢！