In una risposta a un'altra mia domanda , è stato notato che una classe utilizza funzioni di confronto di stringhe standard quando il controllo dell'HMAC nella crittografia autenticata renderebbe la classe vulnerabile agli attacchi temporali contro l'HMAC.
Non riesco a capire come questo sia un problema con un attacco a tempo contro l'HMAC della crittografia autenticata?
Prima di tutto, le implementazioni dovrebbero essere considerate note all'attaccante (in questo caso particolare la fonte viene semplicemente pubblicata), quindi l'unica cosa segreta sarebbe la chiave. Seguendo questa linea di ragionamento, in che modo una funzione di confronto a tempo costante nell'implementazione protegge da qualsiasi cosa? (Mi aspetterei che l'attaccante lo rimuovesse semplicemente, se usasse lo stesso codice).
E in secondo luogo, se considerassi l'implementazione come una black-box, il confronto è contro un HMAC dei dati con una chiave derivata PBKDF2. Non tentare un attacco di temporizzazione contro l'HMAC essere a) tanto lento quanto provare a forzare una password protetta da PBKDF2 b) non rivelare realmente alcuna informazione utile in qualsiasi tentativo di decifrare i dati? (l'HMAC è anche aggiunto al testo cifrato, accessibile a chiunque abbia accesso ai dati crittografati).
Quindi, cosa mi manca qui, perché gli attacchi temporali in questo scenario sono considerati un rischio da proteggere?
Aggiornamento rapido: Capisco come funzionano gli attacchi temporali , ma non capisco cosa si otterrebbe impiegando un attacco a tempo in uno scenario in cui la funzione di decifrazione assomiglia a:
/**
* @param binary $data Where $data = salt, IV, encrypted data, HMAC(salt, IV, encrypted data)
* @param string $password The decrypt-password
* @return string|null plain text if data was successfully decrypted, null otherwise
*/
function decrypt($data, $password) {
...
}