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

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(平均值)的自然变化,即(猜测)sqrt(2000)或大约40.所以三个偏差,+/ - 120或1880-2120应该包含99%的字母 - 你看到的东西更加系统化.

ppps整洁的想法.

ooops我刚刚意识到-muuencode强制base64而不是uudecode算法,但同样的想法适用.