Perché ci sono poche (nessuna?) librerie di crittografia facili da usare?

Perché la crittografia è complessa . Ci sono molte trappole da evitare e terribili conseguenze che possono accadere se ti sbagli. Le risposte a una mia domanda esplorano abbastanza bene alcune delle ragioni. A quale livello di astrazione dovrebbe collaborare uno sviluppatore per quanto riguarda la crittografia?

Detto questo, là sono alcune librerie crittografiche ben astratte là fuori. La libreria di Fernet fornisce un'interfaccia facile da usare per la crittografia simmetrica in entrambi Ruby e Vai . La libreria Keyczar ha implementazioni anche in diverse lingue. Infine, una spina personale per un progetto con cui sono coinvolto, la libreria cryptography per python mira a fornire sia ricette di crittografia di alto livello che primitive di basso livello con ampia documentazione sulle migliori pratiche.

Sono d'accordo con te fino a un punto che non ci sono soluzioni facili. Un famoso esempio recente è l'incapacità di Edward Snowden di insegnare a Glenn Greenwald come utilizzare uno strumento di crittografia a chiave pubblica.

Il paesaggio è stato reso più insidioso da backdoor deliberati (?). Apple, Linux e RSA sono stati tutti nelle ultime notizie per crypto rotto.

So for all the developers that want to encrypt information, we're pretty much destined to get it wrong.

Non sono d'accordo. Mentre non ci sono soluzioni facili, ci sono molte soluzioni. Il mondo Java ha costruito librerie crittografiche che sono provate e vere e librerie di terze parti come Bouncy Castle (che include HMAC).

Citi la mancanza di verifiche di integrità dei messaggi nella libreria che hai trovato. L'integrità del messaggio (autenticazione crittografica) è un problema strettamente correlato ma separato rispetto alla comunicazione crittografata. Molte librerie fanno entrambe le cose. Se una libreria crittografica non la supporta e ne hai bisogno, potrebbe essere trovata in una libreria separata. La pagina di Wikipedia su HMAC ha un elenco di implementazioni in molte lingue.

Vorrei sottolineare che implementare la verifica dell'integrità dei messaggi seguendo metodi consolidati non è la stessa cosa che inventare i propri. Proprio come se scrivessi codice java che ha implementato uno SHA-256 tutto da solo, non conterà come il mio. L'algoritmo è la vera invenzione verificata e verificata qui, non l'implementazione.

Come notato da te e dagli altri, la crittografia è complessa. Ma ancora più importante, la sicurezza è complessa; e i problemi non sono tutti tecnici e non possono essere risolti tutti con la crittografia. Gli algoritmi di crittografia sono solo un piccolo pezzo del puzzle di sicurezza. Di per sé, la crittografia risolve solo un attributo di sicurezza: la riservatezza. Ci sono altri fattori, tra cui l'integrità, la disponibilità, l'autorizzazione e il non ripudio, di cui occuparsi.

Per essere utile, la crittografia deve essere eseguita nel contesto di un protocollo. Il protocollo specifica esattamente quali byte vanno qui e quali byte vanno lì. Se si ottiene la crittografia corretta ma il protocollo è errato, è possibile non riuscire a proteggere l'integrità del messaggio. Il protocollo può essere progettato per proteggere l'integrità del messaggio, ma non è lo stesso della crittografia. Se il sistema è così complesso che i tuoi utenti non riescono a farlo funzionare, non è disponibile. La gestione delle chiavi rimane il problema più grande: se ottieni la crittografia, i protocolli e la complessità risolti, ma fallisci nella gestione delle chiavi o nella distribuzione delle chiavi, non riesci a proteggere l'autorizzazione, il non disconoscimento e persino l'integrità e la riservatezza. Una libreria di crittografia che risolva con successo tutti questi aspetti non esiste.

Un'altra parte del problema è che la sicurezza è definita dall'assenza di attacchi riusciti: dimostrare che un sistema è sicuro è quasi impossibile, perché è impossibile dimostrarlo negativo. È possibile verificare il comportamento corretto, ma non è possibile testare per ogni possibile istanza di comportamento errato. Nuovi attacchi ai protocolli provengono dalla ripetizione di messaggi fuori sequenza, dalla modifica di determinati byte, dalla modifica degli ordini di operazioni, dalla modifica dei numeri di versione dei messaggi, dalla riorganizzazione dei campi, ecc. E altri attacchi devono venire. Nessun sistema è perfettamente testato contro l'ignoto.

Gran parte del problema è che ci sono interessi in gioco in competizione: se vendo "SecuriFoo 2000, la tua soluzione di sicurezza all-in-one", ho poco incentivo economico a renderlo compatibile con "Protect-O-Matic 8.1 ", il mio diretto concorrente nel business (pensa a IMessage). Esiste un mosaico di leggi sulla crittografia in tutto il mondo, che vieta determinati tipi di crittografia in determinati luoghi. E ci sono agenzie governative che hanno interesse a mantenere il mercato così complesso e frammentato che la gente comune non è in grado di selezionare e utilizzare adeguatamente le comunicazioni protette, lasciando crepe insicure nei messaggi che possono essere intercettati.

Il campo è semplicemente immaturo. I praticanti stanno imparando cose nuove ogni giorno, ma anche gli aggressori stanno provando cose nuove ogni giorno. Finché il valore può essere derivato da una violazione della sicurezza, le persone continueranno a cercare di romperlo.

Questa non è una risposta completa, ma un punto che sembra essere stato ignorato dalle altre risposte (John Deters lo tocca, ma lo affronta da un'angolazione molto diversa) qui è questo:

Di solito il punto di crittografia è di impacchettare alcune informazioni che possono essere decodificate o verificate. È abbastanza possibile scrivere una libreria che è molto semplice da utilizzare e che fornisce sia funzionalità di crittografia che di decrittografia. Vedi, ad esempio l'implementazione del Tia Javascript thia che ha 2 funzioni: codifica e decodifica e 2 argomenti: una password e alcuni dati.

Ma in molti casi non controlliamo il software che esegue i entrambi fini dell'operazione - al fine di soddisfare diversi standard e protocolli, l'API con cui lo sviluppatore deve interagire diventa molto più complicata. / p>

Ci sono anche problemi su come vengono rappresentati i dati per l'archiviazione e la trasmissione.

Utilizza HTTPS.

HTTPS è il Nginx della crittografia. La maggior parte delle lingue ha una libreria che può farlo senza configurazione. Funziona. Se devi configurare un server, Labs SSL può dirti se hai fatto bene. Potresti sporcarti le mani e usare direttamente TLS, ma questo sta già entrando in un territorio difficile.

Il motivo per cui non trovi elementi costitutivi convenienti a un livello inferiore rispetto a TLS è che è impossibile utilizzarli correttamente. Anche TLS 1.2, la sesta e attuale versione del protocollo, contiene noti errori importanti .

Ovviamente sto barando un po ', perché in realtà non hai detto per cosa ti serviva la crittografia. Forse non stai affatto trasportando? In ogni caso, HTTPS è un esempio delle soluzioni a questo tipo di problema.