Tutti i moderni schemi di hashing delle password sono deliberatamente progettati per includere una quantità enorme di "lavoro occupato", per limitare la velocità con cui un utente malintenzionato sarebbe in grado di eseguire tentativi di hashing della password. Inoltre, un obiettivo nei nuovi schemi è quello di ridurre la quantità con cui l'hardware per scopi speciali può essere reso più efficiente rispetto all'hardware di costo simile. Se una "unità di lavoro" in ciascuno dei diversi algoritmi è definita come la quantità di lavoro che potrebbe essere eseguita al secondo per dollaro di hardware che è stato ottimizzato per tale attività, l'obiettivo è di massimizzare il numero di unità di lavoro che possono essere fatte in un periodo di tempo accettabile utilizzando l'hardware di produzione. Poiché le macchine commodity si differenziano per l'efficienza con cui possono eseguire varie operazioni, tuttavia, ciò suggerirebbe che algoritmi diversi sarebbero ottimali su diverse macchine di produzione. Ad esempio, sebbene sia preferibile che gli algoritmi siano GPU-ostili se le macchine di produzione non dispongono di GPU, su piattaforme di produzione che possono utilizzare una GPU sarebbe meglio disporre di un algoritmo occupato per la GPU.
Dato l'algoritmo di hashing della password:
hash = secureHash(password, salt)
Using one or more forms of busywork:
busyResult = busyWork(hash, params)
hash = secureHash(hash, busyResult, extraSalt)
Se si presume che secureHash abbia tutte le proprietà necessarie per un hash sicuro, la sicurezza complessiva dipenderebbe da eventuali proprietà crittografiche delle funzioni busyWork utilizzate oltre al fatto che i loro output non sono calcolabili senza eseguire una certa quantità di lavoro? In caso contrario, sarebbe ragionevole favorire diversi tipi di lavoro occupato su diversi ambienti di produzione, se:
-
Ogni record di password includeva un elenco delle forme di occupato che erano state utilizzate per crearlo, insieme ai parametri appropriati.
-
Ogni ambiente di produzione sarebbe in grado di eseguire tutte le forme di lavoro occupato, anche se non in modo efficiente in modo efficiente.
-
In caso di modifiche dell'hardware che richiederebbero l'utilizzo dell'algoritmo della password corrente più a lungo dell'ideale, l'hash della password memorizzata dell'utente potrebbe essere aggiornato in modo trasparente per utilizzare il nuovo algoritmo al successivo accesso dell'utente (l'utente non deve saperlo ciò avveniva).
Cercare di progettare un algoritmo di hash sicuro per ogni diverso sistema di sistema che è stato ottimizzato attorno alle precise abilità di quel sistema sarebbe difficile. Se, tuttavia, il requisito fosse più debole, era solo necessario dimostrare che l'algoritmo busywork era vicino al mezzo più veloce per produrre un determinato output su un determinato sistema e che ogni diverso valore hash inserito nell'algoritmo avrebbe probabilmente produrre output diversi (non è difficile da fare se l'output potrebbe essere molto più grande dell'input), sembrerebbe che produrre algoritmi ottimizzati per piattaforme diverse sarebbe molto più semplice.
Domanda principale: Se la funzione secureHash è buona, e il tempo richiesto per almeno alcune delle funzioni di occupato-lavoro non può essere ridotto efficacemente, ci sarebbe un modo in cui un una scarsa funzione di occupato-lavoro potrebbe compromettere la sicurezza, oltre a prendere tempo lontano dalle migliori funzioni di lavoro occupato?