L'open source è una buona opzione per le librerie di crittografia? [chiuso]

-1

Sto cercando di trovare una buona libreria di crittografia da utilizzare con il mio progetto. Ho trovato opzioni open source come openSSL e molte altre e anche opzioni proprietarie come la libreria di crittografia Intel Integrated Performance Primitives. C'è qualche ragione per cui sceglierei open source vs closed in caso di crittografia? Vedo post simili che suggeriscono che l'open source è migliore per la crittografia per motivi che più occhi possono testare il codice e renderlo robusto. Ma che dire del codice dannoso che potrebbe entrare (es: heartbleed). C'è un compromesso?

    
posta Aldemin 25.04.2016 - 20:27
fonte

2 risposte

2

Il principio chiave dietro il software open source è revisione tra pari . L'idea è che molte persone (esperti e dilettanti) rivedranno il codice nel tempo e che il processo di revisione porterà a un codice migliore e privo di bug. Quindi IMO sì, gli algoritmi di crittografia open source sono migliori degli algoritmi closed source solo per questo fatto. Tuttavia, entrambi i sistemi sono ancora vulnerabili agli Zero-days e simili, anche se con gli algoritmi open source sei potenzialmente meno vulnerabile a causa della quantità di revisione tra pari.

    
risposta data 25.04.2016 - 20:35
fonte
6

Qualsiasi risposta a questo sarà pura speculazione: non c'è una risposta giusta.

Detto questo, la mia opinione è che OpenSSL è almeno buono come qualsiasi libreria crittografica a codice chiuso. Considera che github elenca 175 contributori al progetto openssl e 1.442 forchette, mentre Google studioso trova 17.400 articoli accademici per " OpenSSL". Vai avanti e trovami una libreria crittografica a codice chiuso che ha ricevuto tante ore di sviluppo uomo e tanto controllo accademico!

Il solito argomento a favore della crittografia a codice chiuso è che mentre ci sono quasi certamente più bug e vulnerabilità, si spera che rimangano sconosciuti. Per me, non è molto rassicurante.

Dici anche:

But how about malicious code that might get in?

Direi che è in realtà più facile ottenere backdoor inseriti in codice closed-source. Il governo paga (o ordina il tribunale) una società, il software backdoor viene distribuito. L'unico esempio di ciò che conosco (perché è stato esposto) è lo scandalo Dual EC DRBG di RSA Security , secondo per Wikipedia:

According to the Reuters article which revealed the secret $10 million deal between RSA Security and NSA, RSA Security's BSAFE was most important distributor of the [Dual_EC_DRBG] algorithm.2

Al contrario, il kernel linux aveva un famoso tentativo di backdoor in 2003 in cui un utente malintenzionato ha rubato le credenziali al server di controllo del codice sorgente backup e ha inviato un cambio di codice sperando che sarebbe volato sotto il radar e messo in produzione. Questo è uno sforzo molto maggiore che consiste nel pagare una società e è stato catturato entro 24 ore - con uno dei miei messaggi preferiti di lista di posta di tutti i tempi:

it looks like an attempt to backdoor the kernel, does it not?


It sure does. Note "current->uid = 0", not "current->uid == 0". Good eyes, I missed that. This function is sys_wait4() so by passing in __WCLONE|__WALL you are root. How nice.

    
risposta data 25.04.2016 - 20:36
fonte

Leggi altre domande sui tag