Qualsiasi motivo per usare bcrypt, pbkdf2, scrpt per altre cose oltre alle password? [chiuso]

0

Diciamo che voglio hash alcuni dati, usando SHA256, per dimostrare di sapere qualcosa. Forse è il mio ID segreto per qualcosa.

Nella realtà delle password siamo passati da hashing - > hashing + salt - > Problemi rigidi della cpu - > CPU + problemi di memoria rigidi. Tuttavia, la ragione principale per cui abbiamo fatto tutto questo è perché le password sono (nel mondo reale) molto basse sull'entropia poiché le persone usano "123456" come password. Dal momento che i siti Web vengono compromessi continuamente, abbiamo iniziato a provare a proteggere queste password di bassa entropia dall'essere violati dalla forza bruta.

Tuttavia, ci sono molti altri casi in cui l'input non è "cattivo". Diciamo che invece voglio hash il mio ID di sincronizzazione bittorrent segreta, il mio ID di portafoglio bitcoin o qualsiasi altro tipo di identificazione segreta. Non c'è un singolo round di SHA256 abbastanza qui e per il prossimo futuro? Anche con la NSA, il cluster più grande al mondo di ASIC per la forza bruta SHA256.

Ho visto persone che usano algoritmi come bcrypt / scrypt in molti contesti piuttosto che password, e ovviamente non fa male - ma c'è qualche ragione per cui un singolo hash di SHA non è abbastanza buono? (Supponendo che il mio input abbia un'entrata sufficientemente alta)

    
posta Markus 07.02.2014 - 16:29
fonte

2 risposte

2

Le funzioni di password - (e le funzioni di derivazione delle chiavi basate su password, nel caso di PBKDF2) sono progettate per far fronte alla bassa entropia delle password: partono da una brutta situazione (segreto iniziale è vulnerabile a una ricerca pratica esaustiva) e applica i sali e la lentezza (per prevenire attacchi paralleli / precomputati, e per rendere più esauriente la ricerca) in modo che questa cattiveria possa essere tollerata in una certa misura.

Se il tuo segreto iniziale ha sufficiente entropia per resistere alla ricerca esauriente, non è necessario utilizzare una funzione di hashing della password. Se hai un codice segreto a 256 bit che è stato generato correttamente , quindi bcrypt o scrypt o qualunque cosa non farà alcun bene aggiuntivo. D'altra parte, se il tuo segreto iniziale ha una bassa entropia, anche se non è una "password" di per sé (ad es. Qualche valore derivato dalla biometria, supponendo che tu possa trovarne uno che è in qualche modo segreto e può essere girato in modo affidabile in un valore che non si muoverà troppo per un dato individuo), quindi le funzioni di "password" -hashing saranno uno strumento appropriato.

La funzionalità di base delle funzioni di elaborazione della password come bcrypt è di convertire un valore di input a bassa entropia in un formato non regolare in un bel valore di hash (per la verifica) o una chiave simmetrica (per la crittografia simmetrica) in un modo che migliora resistenza pratica alla ricerca esaustiva (che è possibile a causa della bassa entropia). Le "password" sono solo un caso molto comune di "segreto di bassa entropia con un formato non regolare".

    
risposta data 07.02.2014 - 17:38
fonte
0

Diciamo che voglio hash alcuni dati, usando SHA256, per dimostrare di sapere qualcosa. ... Tuttavia, ci sono molti altri casi in cui l'input non è "cattivo".

Poni le seguenti domande, ma rispondi nel peggiore dei casi (dal tuo punto di vista) che esisterà tra adesso e quando in futuro prevedi che non ti interesserà più di un attaccante che trova e / o pubblica cosa ti stai nascondendo. Nel tuo caso, "ciò che stai nascondendo" potrebbe essere l'ID del tuo portafoglio bitcoin, ecc.:

Qual è il valore di un utente malintenzionato che scopre cosa stai nascondendo?

Qual è lo spazio delle chiavi più grande che un utente malintenzionato dovrebbe cercare per indovinare cosa stai nascondendo? Cioè attacco di forza bruta.

Qual è lo spazio di chiavi più piccolo che un utente malintenzionato dovrebbe cercare per indovinare cosa stai nascondendo? Cioè attacchi di dizionario basati su regole, punti deboli negli algoritmi di hashing, non tutti i bit sono casuali, punti deboli nell'RNG che hanno aiutato con ciò che si sta nascondendo, punti deboli in altri algoritmi, ecc.

PBKDF2 (o HMAC, che include) aumenta lo spazio delle chiavi più piccolo? Scrypt? Bcrypt?

Quali sono le probabilità che venga scoperto un difetto di cui non sei a conoscenza ora?

A quale velocità un ricercatore mal finanziato può cercare spazi chiave (supponiamo $ 5kish, quindi forse 8 GPU di fascia alta o 10 CPU molto buone - un adolescente con genitori ricchi, un hobbista, un membro di StackExchange). Un aggressore moderatamente finanziato? Un attaccante ben finanziato? Un megacorp o un governo?

Quale livello di attacco ti interessa?

Quanto tempo / membro di CPU in più per una di queste tecniche potresti spendere senza metterti in imbarazzo? Ti scomodo solo un po '? Inconvenienti moderatamente? Ti dispiace molto?

Qual è la possibilità della tecnica che scegli di aiutare un aggressore rispetto alla tecnica che stavi considerando in precedenza? Ad esempio, PBKDF2-HMAC-SHA-256 non è peggiore di SHA-256, poiché condividono lo stesso hash di base, ma il primo ha una protezione notevolmente maggiore contro determinati tipi di attacchi.

Prendi queste risposte e applicale a un'analisi del rischio costi-benefici. Vai con la tua risposta.

Per quanto mi riguarda, userò almeno come minimo molti round di qualsiasi dei tre che mi piacciono non mi disturba affatto, e molto probabilmente di più - tendo a pensare che 4-8 secondi di attesa non sono un problema quando Io, un umano, sto cercando informazioni segrete. Scala le iterazioni nel tempo come meglio credi.

    
risposta data 07.02.2014 - 17:09
fonte

Leggi altre domande sui tag