Questo generatore di password è influenzato?

Question

C'è un difetto in questo comando per generare password?

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

Dopo aver generato un paio di password con esso, ho iniziato a sospettare che tende a favorire alcuni caratteri. Ovviamente le persone sono brave a vedere schemi in cui non ce ne sono, quindi ho deciso di testare il comando su un campione più grande. I risultati sono sotto.

Da un campione di 12.000 password generate (12 cifre), ecco le lettere più comuni e meno comuni e quante volte vengono visualizzate.

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 | + 

Quindi, ad esempio, "I" appare più di 1,5 volte più di "+".

È statisticamente significativo? In tal caso, come può essere migliorato il comando?

Answer 1

sì, penso che sarà di parte. uuencode richiede 3 byte per ogni 4 caratteri in uscita. dato che gli stai dando 8 byte, l'ultimo byte è il padding di alcuni tipi (non casuali) e questo influenzerà il dodicesimo carattere (e influenzerà leggermente anche l'undicesimo).

si può provare

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

(con 9 invece di 8), invece, e dopo i risultati? quello non dovrebbe avere lo stesso problema.

ps anche, non sarà più bisogno di far cadere il "=" padding, dato che è un multiplo di 3.

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

pps certamente appare statisticamente significativa. ci si aspetta una variazione naturale di sqrt (media), che è (indovinando) sqrt (2000) o circa 40. quindi tre deviazioni da quella, +/- 120 o 1880-2120 dovrebbero contenere il 99% delle lettere - stai vedendo qualcosa molto più sistematico.

ppps idea pulita.

Ops Ho appena realizzato -m per le forze uuencode base64 piuttosto che l'algoritmo uudecode, ma la stessa idea si applica.