Perché i metodi di crittografia sono scelti da ciò che non è rotto invece di ciò che è possibile?

La semplice risposta è, non è così semplice.

Esiste una serie di ragioni per questo.

Per prima cosa, prendiamo in considerazione la nozione di:

"What is not broken, instead of what is possible?"

Al di fuori delle informazioni algoritmi teoricamente sicuri, gli algoritmi tutti rientrano nella categoria di "non è ancora rotto" per alcune nozioni di sicurezza semantica. Ciò include intere classi di sistemi che non abbiamo (in uso oggi) buoni sostituti quantistici per, come algoritmi asimmetrici per le firme digitali e lo scambio di chiavi in TLS. Non esistono algoritmi resistenti quantistici per problemi come lo scambio di chiavi e le firme ... Non abbiamo ancora capito come possiamo usarli praticamente ancora, e in casi anche fare abbastanza ricerche per essere sicuri che siano in realtà ragionevolmente sicuro. Quindi "ciò che è possibile" è più accademico che pratico, anche nel mondo dei sistemi iper-scala.

Su quella nota, performance. Anche nel mondo dei sistemi iper-scala, le prestazioni sono fondamentali, anche per i giocatori più grandi. Google, per esempio, è costantemente alla ricerca di modi per radere millisecondi e aumentare il numero di sessioni simultanee che possono servire, e loro (e tutti gli altri) devono preoccuparsi non solo dei loro server ma dell'hardware che il client ha sul altro lato, che può essere un laptop moderno o un desktop di fascia bassa di 15 anni o uno smartphone o un telefono con funzionalità di otto anni con un browser Web di base o per sistemi non Web, un livello basso -potenza dispositivo incorporato, o una smartcard con quasi nessuna risorsa di calcolo.

Su quella nota, compatibilità. Anche nei più moderni processori e software x64 moderni è possibile gestire facilmente qualsiasi algoritmo lanciato su di loro, come notato da Matija in altro risposta è possibile implementare algoritmi in un sistema crittografico che non può essere compreso dai consumatori di tali sistemi.

Ulteriori considerazioni evidenziate da SEJPM in un commento è certificazione e politica. Alcuni implementatori di sistemi non hanno nemmeno una scelta negli algoritmi. Un sistema certificato FIPS, ad esempio, può implementare solo algoritmi FIPS. E non solo qualsiasi implementazione di questi algoritmi farà ... L'implementazione stessa deve essere certificata FIPS. Molti sistemi di governo degli Stati Uniti hanno questo requisito. I sistemi russi, d'altra parte, potrebbero essere tenuti ad implementare il proprio algoritmo standard, GOST. Quindi anche in Senarios dove esistono algoritmi migliori (e per FIPS, questa è una realtà, non una teoria) non sono un'opzione per ragioni normative.

Per affrontare tutti questi problemi, abbiamo una varietà di opzioni, e tutte queste opzioni hanno vari vantaggi e svantaggi, e per un uso specifico dobbiamo considerare attentamente i compromessi che rendono la scelta sicuro "opzione soggettiva, e spesso impossibile da misurare senza ricorrere all'opinione individuale sull'impatto di tali trade-off. E, come abbiamo visto, a causa dei requisiti di prestazioni e compatibilità, la sicurezza stessa è un compromesso valido da fare per produrre un intero sistema che funziona nominalmente in modo ottimale bene.

In breve, compatibilità. Certo, puoi selezionare solo i cifrari più sicuri solo nel TLS più recente ed essere sicuro per un periodo di tempo più lungo. Tuttavia, metà delle persone su Internet non sarebbe in grado di contattarti.

Potrebbe andare bene per te (ad esempio, sui server che uso esclusivamente per me stesso, lo faccio esattamente). Per altri usi, perdere anche alcune percentuali dei clienti (come quelli che ancora usano Windows XP non supportati), ad esempio) è inaccettabile, e supportare un codice più debole per un po 'di tempo è la soluzione da usare, anche se più lavoro.

Ho l'impressione di non aver interiorizzato questi principi:

1. La sicurezza riguarda il rischio e il compromesso dei costi, e questi compromessi variano tra utenti e applicazioni.
2. Un sistema di sicurezza non è più strong del suo link più debole - e la crittografia obsoleta spesso non è il link più debole.

Per utilizzare un esempio citato da altri, se un rivenditore online restringe le suite di crittografia accettate dal server pubblico HTTPS, queste non verranno prese in considerazione dai clienti che utilizzano software obsoleti. C'è una chiamata di giudizio da fare qui.

Un'altra considerazione: l'aggiornamento del vecchio software per utilizzare la nuova crittografia è costoso e soggetto a errori e compete con risorse con altri miglioramenti. E # 2 ci dice che alcuni di questi miglioramenti in competizione potrebbero essere corretti per i bug di sicurezza che sono a rischio elevato rispetto alla crittografia obsoleta ma non interrotta.

Tuttavia tieni presente che è prassi normale raccomandare che i nuovi progetti utilizzino sempre la criptazione migliore consigliata al momento dell'avvio. Ad esempio, oggi i crittografi dicono generalmente alle persone di usare SHA-2 in tutti i nuovi progetti, non in SHA-1.