Hai descritto un metodo, ma non l'obiettivo o alcuna circostanza:

1. Qual è la situazione e il tuo obiettivo al suo interno?
2. Di quali avversari vuoi proteggere?

Lo scenario ipotizzato

Suppongo che tu voglia:

• desideri inviare dati,
• senza che un intercettatore passivo sia in grado di ottenere il contenuto,
• dove possiedi entrambi i computer (o forse un amico possiede il computer di destinazione).

In questo caso, c'è un canale alternativo disponibile: puoi parlare con il tuo amico (o te stesso) al telefono o nella vita reale, così puoi dare loro la password. Utilizza un archivio 7z crittografato e inviaci un'email o qualcosa del genere.

Per verificare l'integrità, nel caso in cui un utente malintenzionato attivo abbia manomesso la trasmissione, è possibile calcolare l'hash (generato utilizzando, ad esempio, il comando sha256sum su sistemi basati su GNU) e includerlo in un file in l'archivio 7z. L'archivio stesso ha già dei checksum, ma questo non si qualifica come crittografia autenticata (integrità crittografica + riservatezza), quindi è necessario verificarla separatamente. Potresti anche, quando fornisci la password, dare l'hash al tuo amico in modo che possa controllarlo in questo modo.

Ma potresti anche voler dire ...

• desideri inviare dati,
• a qualcuno che non hai mai incontrato prima (ad esempio un visitatore del tuo sito web),
• senza che un intercettatore attivo sia in grado di ottenere o modificare i contenuti.

In questo caso, come cambierai le chiavi? Qualsiasi password che invii oltre la linea, un intercettore può intercettare. E qualsiasi algoritmo di scambio di chiavi che protegge dalle intercettazioni passive, può essere sconfitto da attaccanti attivi. Il modo in cui https lo risolve è affidarsi a terzi. Avendo un certificato di una di queste parti fidate, come Let's Encrypt , il destinatario può essere ragionevolmente sicuro che le chiavi di crittografia ricevute non provengano da attaccante.

Quindi ciò di cui hai bisogno dipende davvero dalla situazione. Dalla tua descrizione, presumo che un archivio 7z crittografato sia sufficiente; ma se vuoi una risposta più specifica, devi porre una domanda più specifica.

Per quanto riguarda "la crittografia a livello singolo è sufficiente?"

Bene, quanto ti fidi di un determinato algoritmo? Posso venderti un algoritmo super deluxe per soli $ 500, ma nessuno lo ha controllato. Potresti usare AES: progettato dai belgi, usato negli standard USA, e molte persone lo hanno studiato per difetti. Le probabilità che si rompa sono, a mio avviso, trascurabili. Ma forse hai paura che la NSA abbia un AES backdoor, nel qual caso potresti voler usare algoritmi russi come GOST. Ma cosa succederebbe se i russi lo aprissero? È possibile utilizzare entrambi e mescolare i due, ma mentre in teoria non è un problema, in pratica lievi modifiche dell'uso consigliato possono causare guasti catastrofici. Avrebbe l'odore di zuppa cripta casalinga.

Per farla breve: sì, l'utilizzo di un solo livello di crittografia è decisamente sufficiente. (Assumendo una situazione standard). Tuttavia, la domanda è: l'algoritmo è sicuro? Scegli il tuo metodo di crittografia con saggezza!

Non necessariamente

Per rispondere alla tua domanda in generale: Non necessariamente .

Questo non vuol dire che sia uno spreco di tempo.

La crittografia su se stessa non è sempre sufficiente a garantire la riservatezza dei dati, ma le specifiche si basano sui dettagli del tuo caso d'uso.

Un esempio

Ad esempio, supponiamo che tu abbia usato uno schema di crittografia non imbottito come AES-256 in modalità CTR, e hai gestito correttamente i tuoi IV e le tue chiavi, e il tuo sistema è stato progettato per inviare stringhe JSON crittografate nel seguente formato:

{evil:[true|false]}

AES-256 in modalità CTR è abbastanza sicuro, ma la lunghezza dell'output crittografato sarà 11 byte se true e 12 byte se false. Anche altri modi di cifratura ne risentirebbero, anche se forse in misura minore.

Ma come mostra l'esempio pedante: i tuoi dati potrebbero teoricamente essere trapelati dai suoi metadati.

Inoltre

Ora, supponiamo che tu riesca a normalizzare i tuoi dati e salvaguardarne l'output contro la meta crittanalisi,

Se i tuoi dati sono analizzati e utilizzati da un algoritmo, quasi certamente vorrai autenticare la sua integrità (a causa delle note sostituzioni in testo normale).

Ad esempio: se stavi implementando un protocollo web browser senza crittografia autenticata, uno potrebbe essere in grado di scambiare parte del testo cifrato (di solito il capo) e iniettare un tag script o qualsiasi tag risorsa remoto. Questa risorsa iniettata potrebbe essere utilizzata per esporre il contenuto dei dati crittografati.

Una vulnerabilità simile era sfruttata in parecchi client di posta elettronica PGP , consentendo agli aggressori di visualizzare il contenuto di una e-mail senza "rompere tecnicamente la crittografia". "

tl; dr

Utilizza la crittografia autenticata e conosci i tuoi dati. Potrebbe essere necessario proteggerlo contro la meta-analisi.

Se vuoi solo assicurarti che nessuno abbia accesso ai dati semplici durante il transito e che i dati non possano essere modificati, è sufficiente crittografare i dati una volta, supponendo che sia fatto correttamente, ad esempio chiave strong, crittografia strong algoritmo e strong protezione dell'integrità.

Tuttavia, ci sono casi in cui è necessaria una maggiore quantità, come l'autenticazione strong, nascondendo le meta informazioni come chi comunica con chi, nascondendo il tipo di traffico come dimensioni e tempi dei dati ecc. In questo caso si potrebbe voler trasferire i dati già crittografati su un tunnel che fornisce una protezione aggiuntiva.

Alla sicurezza le persone amano parlare di crittografia "a riposo" e "in transito". Sono cose leggermente diverse. La crittografia viene fornita con altre funzionalità oltre a rendere i dati illeggibili per il destinatario. La crittografia dei file viene spesso utilizzata insieme alla firma, provando l'origine del file. La crittografia del trasporto viene generalmente eseguita con una chiave privata all'estremità che dimostra che hai inviato il file nel posto giusto.

Naturalmente, entrambi gli approcci possono essere implementati in modo tale da fornire i benefici dell'altro - ma questo è un po 'più esoterico dell'utilizzo del software non appena è uscito dalla scatola.

Hanno però diversi punti deboli: la crittografia dei file richiede che tu e il tuo corrispondente accettiate una o più chiavi, che dovrebbero essere eseguite (o almeno verificate) tramite un altro canale rispetto al modo in cui si inviano i dati crittografati. La crittografia del trasporto può essere eseguita senza prima concordare una chiave (supponendo che utilizzi un meccanismo basato su certificati - l'ovvio è TLS). OTOH TLS, SSL e SSH non sono algoritmi di crittografia ma protocolli per concordare gli algoritmi e quindi implementarli per il canale. Nel caso di TLS e SSL, la negoziazione è stata storicamente un'area di debolezza: in alcuni casi è stato possibile ingannare un punto finale per concordare un algoritmo relativamente insicuro.

Quindi, anche se non si confrontano perfettamente mele e arance, sono cose diverse, e quindi potrebbe essere un vantaggio rispetto all'utilizzo di entrambi.

Se implementato correttamente, una singola crittografia tramite un protocollo che fornisce crittografia autenticata è sufficiente per verificare:

1. il contenuto del file crittografato non può essere ripristinato senza la chiave segreta,
2. il contenuto del file crittografato non è stato manomesso da qualcuno che non ha la chiave segreta.

La crittografia autenticata utilizza sia una funzione di crittografia per mappare un testo in chiaro per creare un testo cifrato basato su una chiave segreta, ma genera anche un codice di autenticazione dei messaggi (MAC) basato sul testo e una chiave segreta. Qualcuno che non ha la chiave segreta non può generare un MAC valido per un messaggio (e qualsiasi destinatario che tenti di decriptare un messaggio danneggiato lo scoprirà rapidamente). Un semplice algoritmo del codice di autenticazione dei messaggi è MAC = Encrypt(Hash(ciphertext), Key) (Encrypt-Then-MAC) in cui aggiungi questo MAC al testo cifrato e lo controlli prima della decrittografia.

Detto questo, ci sono molte situazioni in cui i livelli multipli di crittografia sono appropriati e la norma (anche se ogni protocollo di crittografia fornisce un MAC per verificare l'integrità). Ad esempio, si carica un file già crittografato su un server remoto utilizzando il protocollo SSH ; oppure ti colleghi alla rete Intranet del tuo lavoro tramite una VPN che utilizza IPSec per crittografare il tuo traffico di rete; quindi usi SSH o visiti una pagina web HTTPS su quella VPN; oppure si utilizza la crittografia tramite Wi-Fi e quindi si collega a un sito Web HTTPS, ecc. I protocolli di trasferimento crittografati come SSH o HTTPS possono ancora essere preferiti anche quando si trasferiscono file che sono stati crittografati, poiché è possibile verificare l'identità del server su cui si stanno caricando i contenuti (diversamente da telnet o http, in cui un intercettore di rete potrebbe intercettare le richieste e impersonare segretamente il server corretto e i file non arriveranno mai alla destinazione prevista.) Ciò detto, l'intercettore non sarà in grado di decifrare il tuo file strongmente crittografato senza la chiave segreta ).

Si noti che gli intercettatori della rete in tutti gli scenari possono ascoltare la quantità di traffico inviato e il punto in cui si trova il salto successivo.