Sicurezza di PGP per l'archiviazione a lungo termine

Il limite di 4096 bit sulle chiavi RSA per GPG non costituirà un problema per la sicurezza, a meno che non venga scoperto un nuovo algoritmo, migliore e più veloce per crackare le chiavi RSA, e quindi qualsiasi affermazione sulla forza fornita da alcune dimensioni chiave specifiche sarebbe essere eccessivamente speculativo Nuovi algoritmi per crackare RSA non si verificano spesso; l'ultima volta era circa 1989 per il numero generale di campo Sieve (la maggior parte dei progressi scientifici su GNFS dalla fine degli anni '80 riguardano implementazioni pratiche di GNFS e molte ottimizzazioni su piccola scala, ma l'algoritmo principale non è cambiato da allora).

Si noti che la crittografia asimmetrica non risolve il problema della riservatezza; lo sposta semplicemente: devi ancora memorizzare la chiave privata da qualche parte. In definitiva, per il tuo problema di memorizzare le password, proteggi la tua chiave privata con una "passphrase master" e questa è la crittografia simmetrica. Puoi semplificare l'intero processo applicando la crittografia simmetrica direttamente sul tuo file pieno di password (GnuPG supportalo ). Diventare completamente asimmetrici è interessante (nel tuo contesto) solo se vuoi memorizzare una nuova password da una macchina da cui non hai accesso alla chiave privata e su cui non vuoi digitare la tua passphrase.

In ogni caso, un punto difficile è quando si tratta di utilizzare le password memorizzate. Devi eseguire la decrittografia su alcuni sistemi. Quel sistema sarebbe stato meglio privo di malware, perché un keylogger avrebbe quindi acquisito la passphrase e / o la propria chiave privata (se si utilizza la crittografia asimmetrica). Idealmente, dovresti farlo solo dai tuoi dispositivi. Questo è quello che faccio quando viaggio:

• Il mio dispositivo è un netbook basato su Linux.
• La directory /tmp è un file system basato sulla memoria (quindi quello che scrivo non arriva mai all'SSD).
• Non è stato configurato alcun swap (quindi ciò che è in RAM non viene mai scritto nell'SSD).
• Decifro (simmetricamente) il mio file-di-password in /tmp , leggo la password, poi la digito e quindi elimino il file decrittografato.

Naturalmente, se a quel punto hai il tuo dispositivo, perché dovresti archiviare il file crittografato nella tua e-mail? Potresti tenerlo direttamente sul tuo dispositivo.

(A proposito, dal momento che le e-mail possono archiviare file arbitrari come allegati, non è necessario limitarsi ai formati specifici dell'email OpenPGP e S / MIME . L'utilizzo di questi elementi semplifica le cose in quanto puoi sperare in la tua applicazione di posta per eseguire la decrittografia, invece di dover ricorrere ad alcuni strumenti da riga di comando.Tuttavia, posso dire che gli strumenti della riga di comando ti danno più controllo su dove vanno i tuoi dati, ad esempio in una RAM- supportato /tmp filesystem.)

Spero di non andare troppo lontano dall'argomento discutendo l'ultima parte della tua domanda in modo un po 'più dettagliato poiché penso che Tom abbia trattato tutto il resto.

Inoltre non sono riuscito a trovare alcuna indicazione che gpg utilizzi un MAC sul testo cifrato.

Ultimamente, ho utilizzato l' utility di scrypt per crittografare un file con una password (sia un file di password che file tar per i backup). Non c'è nessuna build di Windows di cui io sia a conoscenza (suppongo che cygwin possa funzionare), né sono a conoscenza di alcuna altra applicazione che supporti il particolare formato di file che produce. È ancora più vicino a quello che sto cercando rispetto ad altre utility che sono stato in grado di trovare e che potrebbero funzionare per te. Ha intenzionalmente poche opzioni; IMO, potrebbe usare un'opzione di verifica poiché in questo momento devi decifrare su / dev / null per farlo. La documentazione non è eccezionale; devi guardare il file FORMAT nella distribuzione di origine per scoprire cosa sta facendo, che è in esecuzione scrypt sulla password con 256 bit casuale salt per ottenere due chiavi a 256 bit, una usata per AES-256 in CTR modalità con nonce fisso di 0 e l'altra per HMAC-SHA256. Inoltre, la stima del tempo usata con l'argomento -t non è accurata; Trovo che ho bisogno di usare -t 25 per ottenere 5 secondi di rafforzamento della chiave. L'altra cosa fastidiosa è che non funziona abbastanza per ridimensionare l'output di decrittografia a un valore inferiore, quindi è necessario trovare un punto in cui archiviare l'output decrittografato quando lo si guarda e lo si modifica. Ho usato un file system di memoria (con o senza crittografia swap, che sarebbe comunque una buona idea) o directory home crittografata. Usa l'implementazione OpenSL AES e altro codice crittografico copiato dalle altre utility simili dell'autore ma non costruito come libreria separata (il che sarebbe bello, qualcun altro l'ha fatto ma al momento non riesco a trovare il link). Il principale vantaggio è che fa la cosa fondamentale "rafforzare la password quindi crittografare quindi autenticare" in una quantità piuttosto piccola di codice.

In precedenza ho usato ma non consiglio seccure , che utilizza chiavi pubbliche basate sulla crittografia a curve ellittiche e derivata direttamente dalla password (sfortunatamente tramite un solo round di SHA256). Sembra abbandonato, ha prodotto file corrotti e richiede un sacco di memoria bloccata per funzionare. Mi piace quello che tenta di fare e vorrei che ci fosse una versione funzionante di questo.

Non ho trovato dei buoni archiviatori con "crittografare poi MAC" e una crittografia moderna che si occupi di cose come i buchi dei file e le autorizzazioni UNIX. Penso che la situazione sia migliore se si desidera archiviare lo stile zip ma non ho consigli specifici.

Speriamo che nei prossimi anni ci siano utility standard ampiamente disponibili per fare questo genere di cose facilmente che non siano complesse come le opzioni attuali e utilizzare la crittografia corrente.