Perché manteniamo le nostre chiavi segrete, piuttosto che i nostri algoritmi? [duplicare]

Non vogliamo solo segretezza. Vogliamo la segretezza quantificabile . Il punto non è solo quello di garantire la riservatezza dei dati, ma anche di essere in grado di sapere che abbiamo effettivamente assicurato la riservatezza dei dati.

Quando abbiamo un algoritmo pubblico e una chiave segreta, la segretezza può essere quantificata. Ad esempio, se utilizziamo AES con una chiave a 128 bit, allora sappiamo che un utente malintenzionato dovrà provare una media di 2 ¹²⁷ possibili chiavi (vale a dire troppe per farlo effettivamente) per trovare quella giusta.

Se invece tentassimo di utilizzare un algoritmo segreto, dovremmo affrontare tre grandi sfide:

• Come spiega @Xander, creare un algoritmo di crittografia sicuro è terribilmente difficile. L'unico metodo conosciuto che offre una discreta affidabilità è il design pubblico: pubblicare l'algoritmo, liberare centinaia di crittografi su di esso e vedere se riescono a trovare qualcosa di sbagliato in esso. Se, dopo un paio di anni, nessuno di loro ha trovato nulla di male nell'algoritmo, allora probabilmente non è troppo debole. Con un algoritmo segreto, devi fare tutto quel lavoro di revisione incrociata da solo, il che non è fattibile in una quantità di tempo decente.

• Non sappiamo quanti "algoritmi di crittografia decenti" possano esistere. Un utente malintenzionato può tentare di enumerare i possibili algoritmi, dove "possibile" significa "ciò che il progettista potrebbe aver inventato". Parte del problema è nel regno della psicologia, quindi la quantificazione sarà difficile.

• Un algoritmo segreto esiste ancora come codice sorgente su alcuni computer, binari compilati su alcuni altri e nella testa di almeno un designer. A meno che tutti i computer di sviluppo coinvolti e il cadavere del progettista non siano stati disciolti in un grande calderone acido, è molto difficile impedire a quel "algoritmo segreto" di filtrare ovunque. D'altra parte, una chiave segreta è un piccolo elemento che può essere gestito in modo più efficiente e tenuto segreto (memorizzato solo nella RAM, eventualmente ricostruito da un algoritmo di scambio di chiavi come Diffie-Hellman ...).

Poiché l'algoritmo probabilmente perde, si può anche considerarlo pubblico e affidarsi solo alla segretezza della chiave. Rendendo effettivamente pubblico l'algoritmo, puoi beneficiare di una revisione estesa da parte di altre persone, il che è una precondizione quasi inevitabile per raggiungere la sicurezza.

Ci sono un paio di cose da considerare.

In primo luogo, arrivare a un algoritmo di crittografia sicura è difficile. Non è un tipo di duro, ma davvero difficile da comprendere che non possiamo dimostrare che gli algoritmi di crittografia siano effettivamente sicuri, ma solo dimostrare che con ciò che sappiamo, non sappiamo come romperli con uno sforzo di meno di 2 ^ n per qualche grande valore di n. E così, l'unico modo per essere ragionevolmente sicuri che non ci siano disastrosi difetti in un algoritmo (e ci sono praticamente in tutti gli algoritmi progettati da amatori, e molti disegnati da professionisti) è sottoporli a una rigorosa revisione da parte di persone qualificate. Quindi, se un algoritmo è controllato, non può, per definizione, essere segreto. D'altra parte, se non è controllato, non può essere considerato sicuro da nessuna misura ragionevole.

In secondo luogo, vi è la questione pratica del segreto a lungo termine. Se hai fatto affidamento solo sull'algoritmo per la segretezza, corri il rischio di dover modificare l'algoritmo se dovesse essere scoperto. È difficile, e comporta la modifica di ogni singola implementazione dell'algoritmo, che è costosa e dirompente. Se la chiave è l'unico segreto, le chiavi possono essere cambiate a basso costo e facilmente, il che rende gli schemi basati su chiavi molto più interessanti.

In definitiva, la crittografia moderna si basa sul principio di Kerckhoffs che afferma che: Un cryptosystem deve essere sicuro anche se tutto ciò che riguarda il sistema, ad eccezione della chiave, è di dominio pubblico. Questo perché con la consapevolezza di ciò che abbiamo, questo è davvero l'unico modo ragionevole per approcciare la progettazione di crittosistemi seria e sicura.

Lo schema che hai proposto utilizza la sostituzione di base. La mappatura, per quanto complicata, è (7 - 10) * 2 = -6. Quindi usare l'analisi della frequenza sul testo cifrato fornirebbe il testo in chiaro. In questo momento, la stringa che stai usando è troppo breve per qualsiasi analisi, ma dato il tempo, la quantità di dati che utilizza lo stesso schema fornirà i mezzi per ottenere il testo in chiaro.

Una volta lungo questo percorso, potresti considerare come viene generato il testo cifrato se la funzione viene modificata, come ogni 12 lettera o ogni 18 lettera, solo per confondere la distribuzione di frequenza del testo cifrato. Alla fine incontrerai gli enigmi enc / decoder usati durante la guerra mondiale. E molto presto, l'uso di diffie helman per negoziare in modo sicuro una chiave condivisa in pubblico. La DH è la pietra angolare attraverso la quale le trattative della chiave pubblica sono gestite su Internet. Uno sviluppo piuttosto interessante, dal momento che la chiave utilizzata per inizializzare le macchine dell'enigma richiedeva a qualcuno di trasmettere la chiave in primo luogo. Una cosa difficile da fare tra i combattimenti. Con ciò, il problema dell'uovo e della gallina è stato risolto.

Ora, se solo le autorità di certificazione riescono a controllare il numero di CA di secondo livello, tutto sarebbe meglio.

Una risposta meno accademica:

Immagina di essere il governo di qualche paese. Immagina di aver ingaggiato persone per progettare questo fantastico nuovo algoritmo di crittografia e hai assunto persone per costruire macchine che lo implementano e hai equipaggiato tutte le tue navi e aeroplani e centri di comando mobili, ambasciate e uffici e .. con esso.

E poi il tuo nemico cattura una delle macchine, o il tuo nemico trasforma una delle persone che ha costruito le macchine, o ...

Quale è più facile? Progettare un nuovo algoritmo, progettare nuove macchine e sostituirle tutte? O cambiare la chiave?

Può essere utile pensare a qualcosa come DES non come ad un algoritmo, ma piuttosto come un generatore di algoritmi che, dati 56 bit, produrrà uno degli algoritmi di crittografia 2 ^ 56, la maggior parte dei quali sono circa altrettanto forti; schemi più recenti come AES possono generare algoritmi 2 ^ 128 o più, tutti forti. Progettare da zero un algoritmo di crittografia sicuro è estremamente difficile; prendere un algoritmo sicuro e trasformarlo in un "generatore di algoritmi" che può generare un enorme numero di algoritmi sicuri è, per confronto, molto più facile. Data una scelta tra l'assunzione di alcuni esperti per progettare un algoritmo di crittografia da zero ad un costo di migliaia di dollari o più, o lanciare alcuni dadi e usare i risultati come una "chiave" per qualche altro "generatore di algoritmi", quest'ultimo non solo è molto più facile e più per la maggior parte degli utenti di crittografia, ma evita anche la necessità per loro di fidarsi di un estraneo con la loro segretezza. Se qualcuno tira un dado fisico e usa i risultati per generare una chiave usata per proteggere le informazioni segrete per il suo uso personale, e se vorrebbe non voler mai che qualcuno sia in grado di decodificare i suoi segreti, non c'è bisogno che lui lo faccia mai qualsiasi altra persona o gruppo di individui possiede conoscenze sufficienti per farlo.

Bene, quanti algoritmi riesci a immaginare? Tieni presente che non devono fare affidamento su una chiave per essere diversa, altrimenti stai usando i tasti.

Quanti non condividono il modo di attaccare? Per esempio. replace x with x+10 e replace x with k[d] sono entrambi vulnerabili a un attacco di frequenza delle lettere.

Quanti non sono l'equivalente di 123456 e password i.e. non saranno nella lista dei migliori algoritmi da controllare?

Sono sufficienti per renderlo troppo lento per consentire a qualcuno di controllarli tutti?