La migliore protezione contro un attacco "testo cifrato scelto"?

In primo luogo, un piccolo background cripto. Ti fornirò i link e potrai decidere quanto lontano leggi.

La chiave per evitare CCA / CCA2 (Chosen ciphertext attack) è di non fornire un "oracle" (qualcosa che l'utente malintenzionato può richiedere in modo limitato o volontario). In termini di implementazioni pratiche di questi oracoli, rispondere ai messaggi e-mail crittografati con le cose precedentemente decifrate è un esempio di fornire un oracolo - qualsiasi testo cifrato è stato decodificato e fornito all'autore dell'attacco. , a m

La chiave è non fornire quell'oracolo, a cui ci sono due soluzioni. Uno è per encrypt-then-mac - ad esempio, utilizzare un segreto precondiviso per produrre un codice di autenticazione del messaggio che il destinatario può controllare prima decrittografare. In questo modo, se il testo cifrato non proviene dal mittente, lo rifiuti. Un'alternativa a questo è usare un modalità di crittografia autenticata , un approccio completo e integrato (combina il codice di blocco con un MAC).

Quindi l'approccio per risolvere il problema CCA / CCA-2 è utilizzare un qualche tipo di autenticazione dei messaggi.

Cosa puoi fare ora? Leggi i protocolli usati dai tuoi codici e assicurati che usino qualcosa come EAX o MAC.

Prima di tutto, non progettare il tuo protocollo crittografico! Per favore non essere offeso, ma: se devi fare questo tipo di domanda, non sei qualificato per progettare la crittografia. (Francamente, anche io proverei a evitare di progettare un protocollo crittografico, anche se sono qualificato.)

So che altre risposte hanno suggerito di andare a conoscere IND-CCA2 e crittografia autenticata e crittografare-allora-mac e firme digitali e checksum e cose del genere, e quindi (presumibilmente) implementare la propria crittografia. Personalmente, penso che sia una cattiva idea. Ci sono molte opportunità di rovinare qualcosa, quindi penso che sia un approccio pericoloso. Fortunatamente, non è necessario progettare la propria crittografia: ci sono buoni schemi là fuori che sono stati attentamente controllati da molti esperti, in un periodo di anni. Puoi semplicemente riutilizzarli.

Pertanto, invece di provare a progettare la tua crittografia, ti consiglio caldamente di impegnarti a riutilizzare uno schema esistente e ben controllato. Per sicurezza delle comunicazioni, raccomando TLS. Per proteggere i dati memorizzati, raccomando GPG con messaggi firmati e crittografati (o altro software che supporti il formato OpenPGP). In questo modo, non hai nemmeno bisogno di sapere come proteggere dagli attacchi di testo cifrato scelti; devi solo sapere che TLS e GPG ti proteggono già per te.

Non è fantastico? Ottenete sia una strong sicurezza, che non dovete fare nulla di duro; qualcun altro ha già fatto tutto il duro lavoro. È un vantaggio per tutti!

Prima di tutto, vale la pena analizzare se questo attacco relativamente difficile è davvero un rischio o una minaccia per il tuo sistema e una configurazione specifica. Se potessi fornire un po 'più di dettagli, sarebbe più facile dare un consiglio a riguardo.

In generale, la migliore protezione contro l'attacco del testo cifrato scelto è rendere impossibile l'attacco a entrambi 1) inserire pezzi di dati criptati, in particolare grandi quantità di essi e 2) rivedere le versioni decifrate dei dati che hanno inserito.

La trasmissione dei dati crittografati su SSL potrebbe aiutare a prevenire l'inserimento dei dati nello stream poiché proteggerà l'attacco man-in-the-middle. Un'altra difesa è quella di rilevare messaggi crittografati invalidamente (ad esempio, con checksum o firme digitali) e in caso di verifica della checksum o errore di decrittografia, evitare di fornire all'utente malintenzionato la versione decrittografata dei dati - in questo modo anche se l'utente malintenzionato riesce a inserire testo cifrato , non sarebbe in grado di utilizzare la tua applicazione come "decifrare oracolo".