security - 这个密码生成器有偏见吗？

Question

关闭。这个问题是off-topic .它目前不接受答案。












想改善这个问题吗？ Update the question所以它是 on-topic对于堆栈溢出。

10年前关闭。




Improve this 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)代替并发布结果？那不应该有同样的问题。

ps 同样，您将不再需要删除“=”填充，因为这是 3 的倍数。

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

pps 它肯定会出现统计显着性。您期望 sqrt(mean) 的自然变化，即(猜测)sqrt(2000) 或大约 40。因此三个偏差、+/-120 或 1880-2120 应包含 99% 的字母 - 您正在看到一些东西更加系统。

pps 好主意。

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