这个密码生成器有偏见吗？ [关闭]

Question

这个生成密码的命令有缺陷吗？

head -c 8 /dev/random | uuencode -m - | sed -n '2s/=*$//;2p'

用它生成几个密码后，我开始怀疑它倾向于偏爱某些字符。当然，人们善于看到没有模式的地方，所以我决定在更大的样本上测试该命令。结果如下。

从生成的 12,000 个（12 位）密码样本中，以下是最常见和最不常见的字母以及它们出现的次数。

  TOP 10          BOTTOM 10

Freq | Char      Freq | Char
-----|-----      -----|-----
2751 | I         1833 | p
2748 | Q         1831 | V
2714 | w         1825 | 1
2690 | Y         1821 | r
2673 | k         1817 | 7
2642 | o         1815 | R
2628 | g         1815 | 2
2609 | 4         1809 | u
2605 | 8         1791 | P
2592 | c         1787 | +

例如，“I”出现的频率是“+”的 1.5 倍以上。

这在统计上是否显着？如果是这样，该命令如何改进？

Answer 1

是的，我认为这将是有偏见的。 uuencode 每 4 个输出字符需要 3 个字节。因为你给它 8 个字节，所以最后一个字节是某种（非随机）类型的填充，这会偏向第 12 个字符（并且也会稍微影响第 11 个字符）。

你可以试试

head -c 9 /dev/random | uuencode -m -

（用 9 而不是 8）代替并发布结果？应该不会有同样的问题。

另外，您将不再需要删除“=”填充，因为它是 3 的倍数。

http://en.wikipedia.org/wiki/Uuencoding

pps 这肯定在统计上显着。您期望 sqrt(mean) 的自然变化，即（猜测）sqrt(2000) 或大约 40。因此三个偏差，+/-120 或 1880-2120 应该包含 99% 的字母 - 你看到了什么更加系统化。

pps 好主意。

哎呀我刚刚意识到-m uuencode 强制使用base64 而不是uudecode 算法，但同样的想法也适用。