所以问题是，在任何给定时间，Tweet的哈希值是否适合作为随机种子？这主要是因为Tweet的内容几乎可以是任何东西，因为它是由世界上很大比例的人口生成的。
那，我知道可以通过大量发布特定推文来进行游戏来自多个帐户的字符串连续不断地向Tweet流中注入可预测的种子。因此，如果可以通过将错误的用户名列入黑名单来缓解这种情况，那么使用tweets作为种子是可行的选择吗？
#1 楼
对于通用随机数生成器，您的建议不是一个好主意。如果您需要一个随机数生成器，其输出可以由第三方独立进行验证，那么对于非常特定的用例而言，这可能是有意义的。 。我所知道的最古老的这种方法是RFC2777。RFC 2777中列出的熵的建议来源为：彩票中奖号码
股票的收盘价。特定日期
特定日期的美国国库每日余额
特定日期在纽约证券交易所的交易量
体育赛事
每一个看起来比Twitter上的帖子更不受操纵。
原因这不是一种通用的好方法
您将具有周期性依赖性。在您可以从Twitter检索帖子之前，您需要具有多种用途的随机数，包括：
如果使用IPv4，则IPID标头字段需要随机性。 />如果使用IPv6，很可能需要随机性来配置地址。
需要随机性来分配请求ID。
您需要随机性来实现TCP序列号。
您需要随机性来实现SSL会话设置。
此外，很难估计Twitter帖子的熵。一些单独的帖子可能自己具有足够的熵，但是很多则没有。可以肯定地估计，帖子平均至少具有一点熵，因此，如果将一千个帖子散列在一起，则可能会获得足够的熵。
结果输出受制于Twitter用户的操纵。如果您的算法已知，则用户可以使用最新帖子的不同内容来计算要计算的种子，并选择产生某种程度上适合该用户的随机性的内容。
产生的输出也将受到Twitter的操纵。肯定会有Twitter员工有权访问信息，这将使任何Twitter用户都可以更容易地进行操纵。
对随机数生成器的所有输入将是众所周知的。这对于通用随机数生成器来说很不好，但是在一些非常特殊的用例中可能很有用。
评论
$ \ begingroup $
TCP序列号应该是随机的，以防止TCP劫持，但是SSL可以防御中间人。一个简单的计数器就可以避免在具有相同IP和端口对的TCP会话之间重用相同的序列号，尽管它可能对DOS没有抵抗力？但前提是您对SSL具有良好的随机性。因此，也许您的项目符号列表应该说您想要（不需要）TCP的随机性。同样，对于不是较大数据包片段的每个数据包，IP片段ID只需唯一，而不是随机的。 SSL假定较低的层是不安全的。
$ \ endgroup $
– Peter Cordes
19年1月6日在5:59
$ \ begingroup $
@PeterCordes但是，确保连接安全的随机性不能轻易消除，尤其是对于诸如twitter之类的常见服务而言。一旦这些切换到TLS 1.3，我会说您至少需要64位随机性。也许可以通过实施TLS的特殊版本来解决此问题，但是至少临时DH密钥对的生成会受到影响，并且hello还包含32位随机性。
$ \ endgroup $
–马腾·博德威斯♦
19年1月6日在11:57
$ \ begingroup $
@MaartenBodewes：哦，是的，这里肯定存在catch22或鸡肉/鸡蛋问题，而这个答案是正确的，因为您确实需要安全的随机数才能在Internet上安全地进行通信。但我认为并非仅在TLS的每一层。乱七八糟的随机数或固定种子或非随机序列可用于IP和TCP，尤其是如果您要使用对服务器进行身份验证的加密货币保护数据的安全。但是，如果您想让TLS真正保护您，则它不适用于TLS。
$ \ endgroup $
– Peter Cordes
19年1月6日在12:04
$ \ begingroup $
答案中的随机示例称为马尔可夫过程。
$ \ endgroup $
– Pedro Lobito
19年1月6日在12:08
$ \ begingroup $
为什么要使用股票等公共数据作为种子而不是直接发布种子？无论如何，人们将需要知道您的代码以验证结果，因此，将种子放入其中（硬编码或文本形式）似乎容易得多，并且不易出错。
$ \ endgroup $
– Sebb
19年1月7日，12：39
#2 楼
其他答案提供了很好的清单，列出了不使用Twitter作为熵源的原因。问题的反面是：-为什么要这么做？
通常在平板电脑，PC和手机上阅读推文。所有这些人都可以使用硬件熵源，这些源可以产生真正随机比特的种子来播种任何东西。时代精神是，您希望获得128或256位的熵，然后为加密安全的伪随机数生成器提供种子。这将满足您所有常见的随机数需求。
您可以找到种子资源，例如：-
大多数现代CPU中都内置了RdRand指令。
/ dev / * random作为* nix各种支持的一部分。
Microsoft的Cryptography API。
相机内置在手机和平板电脑中。
除了学术目的，追求Tweety熵没有很多优点。
评论
$ \ begingroup $
我知道有许多更好的来源可以为随机数生成器提供种子。我想了解的是为什么人们可以或不能使用用户生成的社交媒体内容作为播种源。
$ \ endgroup $
–aa8y
19年1月6日，下午5:04
$ \ begingroup $
@ aa8y我希望在您打开“我对密码学一无所知”的背景下提供更安全的替代方法。引用一本1996年版的IT书的话，使我相信您不知道（现在）RdRand这样的通用硬件，也不知道将相机设备用作TRNG的能力。
$ \ endgroup $
–Paul Uszak
19年1月6日在13:40
$ \ begingroup $
dev / urandom不是“种子源”，而是PRNG输出。甚至/ dev / random实际上并不是原始的随机性，它与urandom的机制相同，但是速率的限制是基于估计的来自硬件的传入熵的速率。我认为这同样适用于MS Crypto API。因此只有第一个和最后一个列表项才算作真正的“种子源”。
$ \ endgroup $
–user371366
19年1月7日在6:14
$ \ begingroup $
@ dn3s不是PRNG，而是加密安全哈希的输出，该哈希从多个硬件源获取输入。是的，它可以用于播种目的（假设您没有冷启动VM，这可能会由于仿真等原因而引入初始种子问题）
$ \ endgroup $
– e-sushi
19年2月6日在18:59
$ \ begingroup $
@ e-sushi我想要了解的是urandom本身是种子。我的措辞不好。它可以用作种子源。但是我觉得“源”对它不是一个很好的整体描述，因为它排除了它是种子“接收器”的事实。
$ \ endgroup $
–user371366
19年2月7日在7:52
#3 楼
您将如何决定使用哪种推文？随机吗？这很快就会导致鸡肉/鸡蛋问题。如果选择的推文是一个单词怎么办？那不会增加很多熵。
如果Twitter不可用怎么办？您只是停止依赖熵的服务，还是无论如何都要继续？
如何保持所选推文的秘密？您可以使用TLS，但是TLS需要使用随机数生成器才能运行。
您将如何提前将其列入黑名单？您不预先知道攻击者，对吧？
如果Twitter更改了他的API怎么办？如果tweet收集代理崩溃或返回不良结果，您会继续运行吗？
如果您的政府决定阻止Twitter，该怎么办？有很多政府这样做。
如果您选择了一条推文，该怎么办？包含多少熵？
拥有可以提供熵的东西只是第一步。通常，您需要一些本地化且难以影响且易于理解/验证的内容。对于这些要求中的任何一个，Twitter似乎都不是一个很好的选择。
评论
$ \ begingroup $
我对“如果选择的推文是一个单词该怎么办？那不会增加太多的熵”会产生一些问题。因为需要在整个选择过程中而不是最终结果中考虑熵的定义。返回的空字符串”以及其他唯一可能具有真正随机性$ p = 2 ^ {-1000} $的字符串将是1000位强的熵源的一部分。这可能是一个单独的问题，意外加载了其他人将要测试的字符串-即攻击者可能使用的假定生成模型。
$ \ endgroup $
–尼尔·斯莱特（Neil Slater）
19年1月5日，19：22
$ \ begingroup $
@NeilSlater很好。但是，除非您实际枚举了域中的所有可能性，否则我猜您仍然会留下一小粒种子。
$ \ endgroup $
–马腾·博德威斯♦
19年1月5日，19：45
$ \ begingroup $
这个想法是选择我们想要播种随机数生成器时看到的第一个tweet，以避免需要随机选择tweet。至于选择某个大小的推文还是尚未高度转发的推文，应该很容易，对吗？对于政府禁止Twitter，我没有想到这一点，但老实说，它不一定是Twitter。它可以是任何用户生成的难以预测的内容。我想知道那是否足够好。 Twitter只是一个例子。
$ \ endgroup $
–aa8y
19年1月6日在4:51
$ \ begingroup $
是的，好的，我可以看到您想推广这个想法。但是您仍然会遇到启动问题，可用性问题，保密问题-实际上是大多数问题。就像选择最新的推文一样，这很容易受到对手的影响，我什至不想考虑它。
$ \ endgroup $
–马腾·博德威斯♦
19年1月6日，11：53
#4 楼
其他答案已经指出了鸡/蛋catch22问题，即在您拥有随机数之前，可以通过Internet安全地进行通信，还存在其他问题和其他可能的问题。但是，即使是完全远程的无法嗅探您的数据包的攻击者，您也会感到不安。OP评论：
这个想法是选择我们看到的第一条推文当时我们想播种随机数生成器，以避免需要随机选择推文。 [...]
Tweet是公开的，因此攻击者可以使用您的种子库。
平均而言，Tweet吞吐量约为6000条Tweets每秒（来源）。可以在一秒钟内猜出您的tweet查询时间的攻击者的搜索空间约为6000条tweets。您可以说这相当于12.5位的熵，比散列长度小得多。否则，攻击者可以将窗口扩大到1分钟，以获得18.4位的等效熵，而在几秒钟内对蛮力仍然微不足道，可能仅受下载所有这些推文的时间限制。
如果攻击者控制了或知道何时生成种子，就被您搞砸了。他们可以放的时间越紧，搜索空间就越小。更糟糕的是，如果攻击者在所检查的前一秒窗口中找不到匹配内容，攻击者就可以继续使用早些时候的推文来扩大其时间范围。的PRNG将序列暴露给攻击者，因此他们可以测试种子的猜测。使用与您的软件相同的PRNG尝试使用它们，然后检查结果序列是否与他们已经看到的序列匹配。然后，他们很有可能预测将要看到的下一个数字。
出于多种原因，可能存在假阳性匹配导致相同的初始序列：
他们只能看到（或向后工作）
rng() & 0xff（低8位）或rng() % 100（或生成0..99范围的更好方法），而不是每个PRNG步骤的完整32位或64位随机数值。 br /> PRNG具有较大的隐藏内部状态，并且多个初始状态导致相同的随机数序列。 （这已经是必要的，因此知道一个rng结果并不能唯一地确定另一个结果。）但是，通过观察来自同一种子的足够的随机数据，攻击可以非常高地测试种子。
只有6000个可能的候选者，一个给出与您观察到的初始序列相同但实际上不同的机会是微不足道的。
如果您在一个窗口（并且与该时间窗口相对应），您可以检测何时唯一地标识了一条产生您所看到的序列的推文，因此即使您没有看到太多推文，也可以很快“锁定”每次观察到该序列都会产生几位数据。
如果将随机数用作加密密钥，则即使检测到“看似”明文的攻击者仍然可以这种方式进行攻击，即使
检查种子中的哪些（约6000条）推文是否导致种子中看起来理智的纯文本。第一个密钥。
在这几条候选推文中，检查是否从相同序列生成的第二个密钥中生成了看起来合理的纯文本。如果与第一个键有多个不同的，可能相同的纯文本，则可能会排除其中的大多数。如有必要，请重复。
这可能不是最合理的示例，但是这种想法适用于其他类型的情况，您不能直接看到随机序列，而只能使用密码安全的方式它的。但是，如果您具有通过执行攻击目标所采取的所有步骤来测试猜测的任何机制，您仍然可以进行攻击。
或者，如果您可以在某个已知时间触发重新种子，并使用该服务和您自己的已知数据来获取（可能）使用该种子生成的一些第一个随机值，那么您也许可以算出它的种子将继续用于其他用户的请求。
只有6000条推文足够小，您可以开始在其他维度上扩展搜索空间，例如允许其他用户的请求当您将它用作oracle来加密可让您检查的已知明文的oracle时，可能会在您之间滑动。 （或一些等效的东西，它可以让您真正检查PRNG序列的猜测。）
评论
推文不是秘密，因此攻击者会知道它们。想法是，在任何给定的时间点它们都是秘密，因为在给定的微秒内，有多个人可以在世界范围内生产它们。
不要将此帐户twitter.com/big_ben_clock当作种子;-)