Quanto possiamo fidarci di implementazioni open source di librerie crittografiche (di sicurezza)?

Hai tre compromessi: PBKDF vs un altro algoritmo, open source vs closed e la disponibilità di vettori di test.

SCrypt o BCrypt potrebbero darti un po 'più di sicurezza rispetto a PBKDF2. D'altra parte, se c'è un errore di implementazione nel codice (come successo ad Ashley Madison), quindi si ottiene molta meno sicurezza.

Nella misura in cui il codice viene esaminato, tali errori possono essere notati, ed ecco dove avviene il compromesso open source. In teoria, chiunque può guardare il codice. In pratica, devi chiedere quanti esperti hanno guardato. La fornitura di criptoanalisti volontari è piuttosto ridotta, come dimostrato dai difetti di OpenSSL. Con il codice MS PBKDF, ci si può aspettare che qualcuno al di fuori del coder abbia fatto QA, e il codice crittografico riceve un'attenzione relativamente maggiore in Security Development Lifecycle. In assenza di altri indicatori di test di sicurezza, un nugget .NET utilizzato da 100 persone probabilmente ha meno analisi rispetto a un componente Microsoft.

Infine, se la memoria serve, PBKDF ha vettori di test, e gli altri no, il che rende più semplice testare l'implementazione di PBKDF più semplice delle implementazioni di testing di scrypt o bcrypt.

Devo menzionare, anni fa ho librerie crittografiche rintracciate e poi, successivamente, ha lavorato al team di sviluppo della sicurezza di Microsoft, ma non lo fa più. Non penso che ci sia una risposta semplice alla tua domanda.

How much can we trust open source implementations of crypto (security) libraries?

Molto meglio dell'implementazione di closed source.

Quando si tratta di sicurezza che conta davvero, devi seguire il principio "fiducia ma verifica". Confidate che le diffuse implementazioni open source abbiano maggiori probabilità di ottenerlo corretto e abbastanza occhi per individuare gli errori, ma verificare / verificare il codice da soli se è davvero importante per voi.

Con l'implementazione open source, puoi verificarlo autonomamente se è davvero importante per te. Con l'implementazione closed source, hai solo la parola del venditore per questo.

Se non altro, la sfiducia nei confronti delle librerie di sicurezza open source è una buona cosa; fa sì che alcune persone inizino a controllarle prima di utilizzarle, piuttosto che fidarsi ciecamente di un'implementazione perché sono popolari.

Non programmare mai le librerie di crittografia o di hashing, ma usa quelle già esistenti. Quelle già esistenti sono fatte da persone che sono spesso specializzate in esso.

Oltre a questo. La migliore da usare dovrebbe essere open-source al primo posto. Essendo open source più sicurezza, gli esperti / le persone hanno l'opportunità di trovare bug o errori e in tal modo vengono risolti altri problemi. Logicamente, quello che è il più usato è spesso anche il più recensito. Maggiori possibilità sono state risolte su questo problema.

Non puoi davvero controllarti se è sicuro. Trovare errori in un tale algoritmo è difficile. Esempi rapidi . Un esperto di sicurezza probabilmente non li troverà tutti, quindi anche non si fidano di quelli a codice chiuso perché il loro codice non ha raggiunto molti occhi come quello open-source.