Codifica paranoica

Non scrivere il proprio programma di crittografia. Farai qualcosa di sbagliato.

La persistenza dei mezzi di comunicazione di cui parli è un vero problema. Ci sono tonnellate di vecchi documenti memorizzati su nastri da bobina a bobina e non sono rimaste molte attrezzature per leggerlo. Il proprietario dei dati dovrà assicurarsi di passare alle tecnologie più recenti, a seconda dei casi.

Detto questo, 7zip è open-source. Puoi prendere il codice sorgente, crearlo da solo e salvare quel file binario compilato. Se 7zip si chiude in 5 anni, hai ancora la tua copia del file binario, la stessa che hai usato per eseguire la crittografia. Usalo per fare la decrittazione.

Se stai memorizzando i dati per lunghi periodi, ti suggerirei di includere anche alcuni tipi di dati di recupero PAR2 accanto al contenitore crittografato, per riparare il contenitore contro il bit-put letterale.

I migliori strumenti per la crittografia sono standard basati sull'implementazione per revisione. 7 Zip, utilizzando AES ed essere open source soddisfa queste esigenze.

Non sprecare più energia preoccupandoti dello strumento che scegli se soddisfi questi due requisiti di base. Per decenni il punto debole sono stati gli endpoint. Non c'è bisogno di rompere AES, basta rubare la chiave, mettere una pistola alla testa portachiavi se necessario, offrire a qualcuno che ha accesso a un sacco di soldi, se ne vale la pena ... è più facile, più economico e più veloce di cracking AES.

Ciò di cui hai bisogno è la gestione delle chiavi e la protezione della chiave. Come hai intenzione di impedire a qualcuno di rubarlo, e se lo fanno, come farai a sapere che ce l'hanno? Tieni presente che la modifica della chiave è difficile, in quanto è necessario decrittografare e crittografare nuovamente tutti i dati. I tuoi backup diventano inutili (a meno che tu non mantenga la vecchia chiave, che quasi sconfigge cambiandola). Suggerisco un po 'di leggere :) lettura del tempo letto - Bruce Schneier - Secrets and Lies sarebbe un buon inizio.

crittografia indipendente dall'applicazione / software ... dove cercare in caso di scrittura del mio programma di crittografia?

Sì, i dati future proofing sono una buona idea. Con scegliere un buon formato di file - preferibilmente un formato "aperto" che ha già diverse applicazioni in grado di leggerlo - rende più probabile che almeno una applicazione esista (o possa essere creata) in futuro, in modo tale che possiamo leggere tali dati in futuro.

Sono d'accordo con "insta" che non c'è nulla di significativamente migliore dell'uso della crittografia AES con uno qualsiasi dei formati di archivio come 7z, quindi memorizzare in più posizioni: copie di quel file crittografato o volumi di recupero PAR2 generati da quel file di archivio crittografato. E anche la memorizzazione della passphrase di crittografia in alcuni punti, in modo che possiamo trovarla di nuovo in futuro.

Le applicazioni che supportano già la decrittografia di dati archiviati in quel formato di file 7z crittografato con AES standard includono l'archiviatore 7-Zip, sevenzsharp , Ark, PeaZip, File Roller, e una dozzina di altre applicazioni .

Scrivere il proprio programma di crittografia / decrittografia interamente da zero probabilmente non produrrà nulla di meglio - ed è altamente probabile che produca qualcosa di molto peggio - che usare alcuni preesistente libreria AES o applicazione.

Tuttavia, il processo di scrittura di un programma simile può essere altamente istruttivo.

In linea di principio, è possibile implementare AES-256 "da zero" direttamente da AES: FIPS -197 documento standard, in qualsiasi linguaggio di programmazione. Se non si dispone già di un linguaggio di programmazione preferito (o una lingua che hai già selezionato come vuoi fare più pratica usando), Ho sentito che Python è popolare tra le persone che insegnano un primo corso di programmazione ( Criteri per la selezione della lingua per il primo corso di programmazione ).

Tuttavia, gli standard FIPS sono un po 'difficili da leggere. Se vuoi scrivere un'altra implementazione "da zero" di AES, ti consiglio (in nessun ordine particolare):

• implementa un programma per decodificare i file crittografati in formato Ciphersaber ".
• implementa un programma per decrittografare i file crittografati con il blocco temporaneo perfettamente sicuro.
• Leggi attentamente Wikipedia: Advanced Encryption Standard
• sfoglia "Risposte giuste crittografiche"

Ognuna di queste cose ti aiuta a imparare cose che rendono il documento standard più facile da capire.

Posso ancora decifrarlo in 10 anni?

Il formato file per i contenitori true-crypt è documentato e relativamente semplice. Scrivere un decryptor non dovrebbe essere difficile. La parte complessa è il file system, ad esempio NTFS che memorizza i file con il contenitore. Ma dal momento che ci sono driver open source per NTFS, non mi preoccuperei troppo di questo.

Quindi non mi preoccuperei che i dati diventino illeggibili. Perdere il testo cifrato è molto più probabile che non essere in grado di decrittografarlo.

Quanto è sicuro?

Riguardo alla sicurezza, la forza di AES è probabilmente sufficiente, e se sei veramente paranoico sul progresso della criptoanalisi, puoi usare le catene di cifratura.

Ci sono altri problemi:

• Un utente malintenzionato che vede più revisioni del contenitore può vedere quali blocchi sono stati modificati. Questo è in genere il caso se si ospita un contenitore nel cloud. In particolare questo rivela volumi nascosti.
• La funzione di derivazione della chiave che trasforma la password in una chiave è piuttosto debole. Usa solo 1000 o 2000 iterazioni, il che rende abbastanza veloce la bruteforce, ad esempio il costo per indovinare la password è piuttosto basso. scrypt con parametri ben scelti renderebbe bruteforce più difficile di un fattore di un milione circa. Ciò significa che devi scegliere una password di entropia molto alta.
• Nessun controllo di integrità. Un utente malintenzionato può modificare blocchi arbitrari del contenitore, modificando il testo in chiaro associato senza che TrueCrypt se ne accorga.

Mentre TrueCrypt ha i suoi difetti, è molto improbabile che un principiante possa produrre qualcosa di più sicuro.

AES è la strada da percorrere, è l'algoritmo di crittografia standard corrente, il che significa che è quello che ottiene più attenzione e tentativi di cracking della vita reale, un grande valore per valutare la sicurezza dell'algoritmo di crittografia.

Puoi usare AES256 per sfruttare la chiave più lunga, 256 bit di chiavi di crittografia asimmetriche stanno uccidendo troppo per la comprensione (realistica) di oggi delle prove future.

Se vuoi di più, puoi ricorrere a più concatenazioni di crittografia, ad esempio AES + Twofish + Serpent, che è valido per il consenso attuale.

Tuttavia, la verifica futura sarebbe alquanto complicata: non è possibile ipotizzare possibili innovazioni matematiche, e persino fare proiezioni sulla crescita della potenza di calcolo in uno o alcuni decenni introduce enormi livelli di incertezza.

Questo, come da backgorund teorico, ma la prospettiva implementazione dell'utente finale è spesso il punto critico, e questo è il punto principale per cui nessuno senza una solida esperienza in crittografia (sia matematica che realtà implementazioni ) non dovrebbe prendere in considerazione l'implementazione del proprio cryptosystem.

Un software che fornisce la crittografia dovrebbe sostenere una grande quantità di test e auditing (meglio se pubblico, sicurezza per oscurità, come un ruolo del pollice, non funziona), a partire dal codice (contiene codice dannoso? ovvero come può ci fidiamo di Truecrypt dopo i recenti dubbi sulle ultime versioni?) e anche del compilatore (è stato manomesso l'input di codice dannoso?), il software e la piattaforma stessa (non vengono salvati i file temporanei o di memoria? malware in esecuzione? etc), e infine l'hardware - è stato manomesso? è sicuro da attacchi tipo TEMPEST che intercettano i segnali em da tastiera, schermo, circuiti interni: ecco perché alcune soluzioni di crittografia di alto livello funzionano su hardware dedicato.