Quanto è alta l'entropia di questo codice che genera sale? (Non è necessaria alcuna lettura del codice)

Question

Quanto è alta l'entropia di questo codice che genera sale? (Non è necessaria alcuna lettura del codice)

Naviga le tue risposte

#1 da (5 voti)
#2 da (2 voti)

2

Qual è il metodo migliore?

Assunzione: ho una funzione che genera un numero di byte di entropia medio-alta

Step1: Genero 3 di questi byte di entropia medio-alti.
Step2: Ho cancellato questi byte utilizzando un algoritmo crittografico noto (sha256)
Fase 3: Ho tagliato una sottostringa dal risultato.
Fase 4: Io uso questa stringa come mia sale (3 byte di sale)

Quindi, posso fare:

Step1 e 4;
1, 2, 3 e 4;
1, 3 e 4; ecc.

La domanda è quale di queste operazioni aumenta l'entropia e quale no?

Alcuni codici:

function delicious_delicious_salt()
    {
        $string = openssl_random_pseudo_bytes(3);
        //Do I hash this? Do I generate a longer byte string and cut it?
        return $string;
    }

Ciò che in realtà non conosco

Il passaggio di bit pseudo-casuali attraverso un algoritmo di hashing e il taglio di un set di bit pseudo-casuali dall'output producono bit entropici elevati?

Voglio implementare una funzione di generazione di sale per gli hash delle mie password SHA256 sul mio server web, e come esercizio nella mia comprensione personale voglio che sia crittograficamente sicuro come posso ragionevolmente farlo senza diventare pazzo (e prendendo entropia codificata da HID (mouse, microfono, video)).

php authentication cryptography hash salt

posta gal 27.02.2013 - 18:16

fonte

2 risposte

2

Se inizi con 24 bit (3 byte) di entropia, puoi ottenere sempre solo 24 bit di entropia, indipendentemente dal processo che stai attraversando.

Questo perché se inizi con 2 ²⁴ valori di input possibili ed esegui alcuni processi deterministici con loro, avrai 2 ²⁴ possibili valori di uscita. I valori di output possono essere di lunghezza arbitraria (immagina di seminare un codice di flusso con la tua chiave a 24 bit), ma ci saranno ancora solo 2 ²⁴ di essi. Anche le distribuzioni di probabilità corrisponderanno, il che significa che avrai esattamente la stessa quantità di entropia con cui hai iniziato.

In allungamento della chiave (che è praticamente ciò di cui stai parlando), miri a ottenere un valore che è costoso in termini di tempo per essere riprodotto. Quindi puoi prendere il tuo input a 24 bit, cancellarlo N volte dove N è un numero intero abbastanza grande da consentire al processo di richiedere diversi secondi sull'hardware del desktop e utilizzare l'output per qualcosa.

risposta data 27.02.2013 - 18:33

fonte

Leggi altre domande sui tag php authentication cryptography hash salt

Esiste un modo per recuperare un'unità bloccata usando TPM? Può google rilevare il browser

score 5 · Accepted Answer

Entropia è una misura del numero di risultati possibili per l'intero sistema. Se inizi con tre byte casuali, allora ci sono 16777216 possibili input. Indipendentemente da ciò che fai da questi input, otterrai solo 16777216 output possibili; nessuna quantità di hashing & taglio e amp; pregare cambierà qualsiasi cosa - tranne forse riducendo il numero di uscite possibili. Con l'hashing e quindi il troncamento fino ai 3 byte finali, non è possibile garantire che tutti i valori 16777216 per questi tre byte siano possibili. In effetti, dovresti ottenere circa 10 milioni di loro, non di più.

Un salt è buono solo quanto è unico. Non ha bisogno di essere segreto o imprevedibile, ma dovresti cercare di non usare mai lo stesso valore di sale due volte, o almeno di mantenere il riutilizzo al minimo. Se i tuoi sali devono essere contenuti in tre byte e la tua fonte di casualità è di tre byte, il meglio che puoi fare è semplicemente utilizzare questi tre byte casuali come sale. Trattarli è solo una complicazione inutile, che non ha alcun vantaggio in termini di sicurezza e riduce effettivamente lo spazio dei possibili valori di sale, implicando quindi un tasso di riutilizzo più elevato.

Potresti generare sali con un processo non casuale, se puoi mantenere uno stato . Vale a dire, mantieni un contatore, che viene incrementato per ogni sale generato. Il contro-gestione può essere problematico (specialmente nei sistemi multi-frontend), ed è per questo che spesso si preferisce usare la casualità. Ma questa casualità è solo uno strumento per raggiungere unicità . Non è un problema se i sali non sono casuali o seguono una sequenza prevedibile. Il problema è quando si riutilizza un valore salt.