Archivia il traffico crittografato, per successivi tentativi di decrittografia?

Bella domanda.

Direi che possiamo solo preoccuparci, ma non fare molto. Possiamo proteggere i nostri dati secondo gli standard odierni, ma domani potrebbe cambiare l'intera partita. Se i computer quantistici possono davvero cifrare i dati cifrati a una velocità maggiore di quella che possiamo fare ora, allora un codice a 128 bit potrebbe improvvisamente essere un nocciolo. Ma cosa puoi fare al riguardo?

Forse non dovresti trasmettere digitalmente informazioni che saranno comunque sensibili / dannose tra 10 anni ...

Penso che tu sia eccessivamente preoccupato. Se si scelgono le cifrarie corrette per SSL, è improbabile che la crittografia sia il collegamento più debole. Se controlli il server, puoi controllare quali cifrarie verranno utilizzate e quali lunghezze chiave verranno utilizzate. Quindi, se configuri le cose in modo appropriato, per la maggior parte dei casi questo sarà abbastanza buono.

Potresti considerare l'utilizzo di "effimero Diffie-Hellman". L'idea è che ogni connessione SSL genererà una nuova coppia di chiavi privata / pubblica, da utilizzare nella configurazione del canale sicuro, quindi eliminare questa coppia di chiavi in seguito. Questo ha alcuni vantaggi modesti: se il tuo server è suddiviso e qualcuno ruba le chiavi private sul tuo server, il materiale chiave non sarà di alcun aiuto nella decodifica del traffico SSL che potrebbe essere stato intercettato in precedenza. Lo svantaggio principale di Diffie-Hellman effimero è che introduce alcune prestazioni generali.

Ad esempio, la seguente riga nella configurazione di Apache la limiterà alle cipheresi ritenute forti:

SSLCipherSuite AES:!ADH

Ancora meglio è limitare le transeferenziali Diffie-Hellman effimere, che puoi fare usando la seguente riga:

SSLCipherSuite kEDH+AES:!ADH

Quando generi la tua chiave privata sul server, ti consiglio anche di scegliere una lunghezza chiave grande. Una chiave a 4096 bit è probabilmente eccessiva, ma si potrebbe usare se si è molto preoccupati. Una chiave da 2048 bit è quasi certamente adeguata.

Con queste precauzioni, qualcuno che intercetta il tuo traffico e lo memorizza per diversi anni non sarà in grado di interrompere il tuo traffico, data la nostra attuale conoscenza della tecnologia. Richiederebbe un importante passo avanti per rompere questo traffico. Questo è probabilmente ancora vero anche se riteniamo che l'aggressore sia disposto ad aspettare diversi decenni. Più lontano - diciamo, tra 50-100 anni - dubito che qualcuno possa prevedere ciò che potrebbe essere possibile.

Se hai informazioni così preziose che le persone potrebbero registrare il tuo traffico SSL per la decrittografia in futuro, scommetto che stanno cercando di mettere le mani su di esso in modo più diretto in questo momento, e le probabilità sono che avrebbero avuto più successo con mezzi diretti e prima.

Chiunque sia in grado di ottenere testo cifrato trasmesso potrebbe anche archiviarlo per tutto il tempo che desidera, spendere quante più risorse vuole nel tentativo di decifrare le informazioni, e farlo ogni volta che lo desidera - che potrebbe essere in un momento in cui i progressi tecnologici hanno reso tale decifrazione "banale".

Non c'è modo di proteggere completamente da questo scenario che viene in mente se non fisicamente di assicurare un canale di comunicazione contro l'intercettazione o l'uso di cifrari che non possono mai essere "spezzati" come pad monouso con dati veramente casuali.

Quindi di nuovo questo non è un pranzo gratis per un aggressore. Dovranno spendere risorse per catturare testo cifrato e spendere risorse aggiuntive per archiviare le informazioni per un periodo di tempo molto lungo. A meno che il pay-off previsto per decifrare le informazioni (nel tempo previsto prima che l'informazione possa essere decifrata) superi i costi di decifrazione delle informazioni, non vale la pena per un aggressore.

Suggerirei di non trasmettere le informazioni o di trasmetterle in un canale più sicuro come PGP / GPG con un'impostazione di Alta Sicurezza. (RSA-2048 o RSA-4096 per esempio, che dovrebbe rimanere sicuro per 50 e 100 anni di conseguenza, supponendo che il Quantum Computing non esca entro tale data.)

Buona fortuna con tutto ciò che devi nascondere e ricordare non puoi nascondere i segreti del futuro con la matematica .

L'uso della sicurezza è sempre un compromesso. La sicurezza perfetta non può essere raggiunta. L'unico segreto che è ben tenuto è uno che è conosciuto solo da un individuo. Se materializzi questo segreto per comunicarlo, è soggetto ad essere intercettato. Quindi i mezzi che usi per proteggerli devono essere scelti attentamente e di conseguenza al tempo di validità del segreto.

Ovviamente è possibile memorizzare informazioni per decodificarlo in un secondo momento. Il progresso tecnico, l'innovazione della ricerca hanno reso possibile tutto ciò. Ma che senso ha cambiare la password? Questo non è per te avere difficoltà a ricordarlo, ma per contrastare il potenziale furto di esso. Inoltre, se qualcuno intercetta l'hash, vuoi che la tua politica ti obblighi a cambiarla prima del tempo minimo che occorrerà affinché l'attaccante interrompa il codice. Se uso un codice Vigenere per trasmettere un token ad un amico, può essere sufficiente se per il mio amico è necessario meno tempo per consumare il token rispetto all'attaccante per rompere il codice. O Vigenere è considerato pericoloso. La nozione di "sicurezza" non è assoluta.

Come ha detto Chris, forse le informazioni che restano sensibili per più di un certo periodo non dovrebbero essere trasmesse su Internet.