Perché la sicurezza attraverso l'oscurità non è una buona opzione per la crittografia? [duplicare]

Se invii solo un breve messaggio (una o due frasi), sarebbe difficile interromperlo. Tuttavia, una volta che inizi a inviare messaggi di grandi dimensioni o messaggi frequenti, sarebbe probabilmente molto facile interromperli utilizzando tecniche come la frequenza delle lettere.

Ad esempio, con molte semplici tecniche di crittografia, una "a" tradurrà sempre la stessa lettera crittografata. Di conseguenza, con testo sufficiente, è facile capire quali lettere sono basate sulla frequenza.

Puoi persino farlo senza sapere nulla sulla formula che ha crittografato il testo. Persino i cifrari che sembrano nascondere la frequenza delle lettere possono ancora esporlo (vedi questo per esempio). Con i computer, la valutazione della frequenza delle lettere può essere automatizzata e eseguita molto rapidamente.

Ci sono altri modi per rompere i codici; la frequenza delle lettere è solo un esempio facile da capire.

Il motivo per cui fare affidamento sulla sicurezza attraverso l'oscurità è disapprovato, è che una volta che l'algoritmo è trapelato o interrotto, hai completamente perso tutta la sicurezza acquisita dall'oscurità. Quindi se un qualsiasi attore con accesso all'algoritmo lascia la tua organizzazione, o se viene violato, o il codice sorgente (o un eseguibile) di un programma di crittografia / decrittografia viene in qualche modo trapelato / rubato, allora hai completamente perso tutta la sicurezza dal tuo l'algoritmo è oscuro.

Per riguadagnare la sicurezza attraverso l'oscurità, devi trovare un algoritmo crittografico totalmente nuovo, ottenere esperti di crittografia per analizzare in sicurezza il nuovo algoritmo e scambiare segretamente l'algoritmo con tutte le parti che devono comunicare.

Nel frattempo, mentre usiamo algoritmi crittografici standard ben controllati, separiamo l'algoritmo (dove non ti dispiace se qualcuno lo ruba) dalla chiave che è computazionalmente irrealizzabile alla forza bruta (ad esempio, per forzare la forza a 256 -con una chiave simmetrica se ogni protone / neutrone sulla Terra (tutti i 10 ^ 51 di essi) provassero ciascuno un miliardo di chiavi al secondo, in un milione di anni di forzatura bruta, avresti solo 1 su 1000 di possibilità di romperlo) .

Solo la chiave deve essere tenuta segreta. Se si perde una chiave tramite un attacco o si ha bisogno di inviare messaggi in modo sicuro con una nuova festa, non è necessario inventare un algoritmo totalmente nuovo. Hai solo bisogno di generare una nuova chiave.

Con un algoritmo pubblico ben controllato chiunque può venire e cercare di analizzarlo e vedere se ci sono gravi vulnerabilità. Questo non può essere fatto con il tuo algoritmo privato che spesso è molto più debole di quanto possa pensare l'implementatore. (Ad esempio, come Daniel ha menzionato l'algoritmo che hai descritto sarebbe vulnerabile a molti attacchi standard come l'analisi della frequenza delle lettere, l'analisi dei periodi nel testo, l'utilizzo di pattern nel testo in chiaro sottostante, ecc.)

Inoltre, l'utilizzo di algoritmi segreti è significativamente più difficile dal punto di vista dell'usabilità. C'è molto di più che l'utente deve ricordare per ogni scambio con ogni altro utente. Quando trovi qualche file che hai crittografato 5 anni fa o qualcuno ti manda un file, anche se hai ancora la chiave / password sarà molto più facile decrittografarlo se sai che è stato crittografato con AES256 in modalità CBC, dato che il file meta Dati che dichiarano tali informazioni, rispetto al tentativo di ricordare quale tipo di algoritmo di crittografia personalizzata segreto si potrebbe aver utilizzato con questo particolare individuo. Se gli utenti lavorano su una varietà di piattaforme, diventa problematico ottenere che il tuo algoritmo di crittografia segreta personalizzata funzioni perfettamente su tutti loro.

Dai un'occhiata a Questa domanda , in particolare Questa risposta . La tua domanda è quasi identica alla mia e Thomas Pornin ha dato la migliore risposta a questa domanda come sempre. Faresti meglio a leggerlo. Ecco un estratto:

"Security through obscurity" is an expression which uses the term obscurity, not secrecy. Cryptography is about achieving security through secrecy. That's the whole difference: a password can be secret; an algorithm is, at best, obscure. Obscurity is dispelled as soon as some smart guy thinks about bringing a metaphorical lantern. Secrecy is more like a steel safe: to break through it, you need more powerful tools.

L'uso delle chiavi o l'utilizzo di un algoritmo segreto è lo stesso . Permettetemi di ripetere che: l'uso di chiavi in algoritmi di cifratura noti o l'utilizzo di uno speciale algoritmo intelligente della vostra invenzione è lo stesso: in entrambi i casi, c'è un segreto condiviso che può essere misurato in bit di informazioni non elaborate.

Tutti i metodi di cifratura si basano su "oscurità" , che è fondamentalmente la protezione del segreto condiviso . Fondamentalmente, si tratta di mantenere segreto il segreto condiviso . La segretezza della tua chiave è correlata alla casualità di essa (la sua entropia). Meno casuale sarà, più potrei indovinare parte del tuo segreto. Poiché queste parti indovinate non sono più segrete, potremmo dire che il shared-secret è un bit di informazioni non elaborate.

E hai perfettamente ragione nel senso che puoi escogitare un modo che è indissolubile se hai un pre-shared secret abbastanza lungo

Tuttavia, non è necessario essere troppo complicati per l'algoritmo: se si utilizza la crittografia con chiave standard e la chiave è abbastanza lunga (più lunga del messaggio, ad esempio), è abbastanza facile capire che la protezione è perfetta . Come promemoria: una semplice cifratura XOR con una chiave veramente casuale più lunga del messaggio è indistruttibile. Ma non dimenticare quanto segue: hai bisogno di un segreto abbastanza lungo precondiviso (e uno nuovo per ogni comunicazione).

Quindi dov'è il problema? Perché non lo facciamo? Perché il tuo segreto condiviso si consuma ogni volta che lo usi . E alla fine finirai per esaurirlo. L'uso della tua chiave ne dà una parte sottile: ad esempio, guardare ciò che produce il tuo algoritmo fornisce alcuni suggerimenti sottili. Più vediamo uscire dal tuo algoritmo, più modelli saranno notati.

Quindi, nella maggior parte dei casi pratici, ci piace iniziare dal punto in cui Alice e Bob non condividono inizialmente , o almeno questo segreto non è abbastanza lungo per coprire la loro comunicazione. Ricorda che nel tuo caso il segreto è l'algoritmo e nel caso standard è spesso una chiave e chiamiamo questo segreto condiviso .

Quindi, nel caso crittografico standard, le preoccupazioni vengono spostate verso la creazione (più) segreta condivisa . Quindi, la maggior parte degli sforzi vengono poi spesi per trovare il modo di creare un tasto che poi porterà al punto in cui Bob e Alice sono protetti dalla teoria e da una cifratura infrangibile standard: avere un segreto abbastanza lungo .

La maggior parte della comunicazione crittografica odierna funzionerà in questo modo: creare una chiave condivisa al volo (spesso a intervalli regolari in comunicazioni continue), quindi utilizzare qualsiasi banale ma perfetta algoritmo di cifratura (come per esempio XOR) con questa chiave. Diffie Hellman è uno di questi algoritmi. Di solito, la prima parte è la più complicata e può richiedere molta potenza del computer, e la seconda è banale.

Quindi la parte difficile è avere (o generare) abbastanza segreto condiviso per crittografare i tuoi dati.

Per essere sicuro, essere in grado di dimostrare che sei sicuro sono due cose diverse. Idealmente, vuoi essere in grado di appoggiare tutto sul tavolo per l'ispezione.

Ciò implica l'identificazione dei punti di errore e di quali segreti ci sono nel sistema, e di come questi segreti vengano protetti.

Per i segreti dell'infrastruttura, le tue applicazioni possono usare frasi chiave per accedere alle risorse e quelle chiavi sono protette all'interno del firewall DMZ e crittografate con le chiavi della macchina. E puoi provarlo e gli auditor e sono felici.

Per l'accesso degli utenti, l'idea è che solo l'utente conosce quel segreto e puoi dimostrare agli auditor che non stai memorizzando i segreti da nessuna parte in un modo che può essere derivato, tra le altre best practice per le password, e tu può dimostrarlo agli auditor e sono felici.

L'oscurità è quando stai nascondendo qualcosa, e questo è diverso dal tenere segrete le tue chiavi e password. Stai nascondendo il funzionamento del sistema o dell'algoritmo.

Non penso che l'oscurità sia cattiva. Penso che sia probabilmente una cattiva scelta per la maggior parte delle aziende. Non è necessario e può causare complicazioni in tutto il business.