Brute-force una passphrase, generata da 'pwgen 16 -s', di un archivio GPG CAST5

Question

Brute-force una passphrase, generata da 'pwgen 16 -s', di un archivio GPG CAST5

#1 da (4 voti)

2

Una triste storia: uno dei nostri hard disk è fallito. Mentre stava fallendo, siamo riusciti a fare un backup veloce. Poiché è prassi consolidata, abbiamo crittografato il backup utilizzando GPG (tuttavia, il metodo utilizzato da Duplicity, molto probabilmente, è gpg -c ). Sfortunatamente, abbiamo memorizzato la passphrase errata. (Doh!)

Il backup contiene alcuni dati che ci piacerebbe molto recuperare.

Sappiamo che la passphrase è stata generata dal comando pwgen -n 16 -s su una moderna macchina server Ubuntu a 32 bit che è ospite in un host Xen. Potremmo avere una passphrase dello stesso lotto di passphrase di pwgen (è la "passphrase errata"). Ci sono diversi file nel backup, ciascuno codificato con la stessa passphrase.

È possibile provare a forzare la passphrase? Quali strumenti ci sono per questo? Come calcolare il costo e il tempo di un tentativo di recupero della frase segreta di forza bruta? (Supponiamo, per esempio, che siamo disposti ad affittare istanze di GPU Amazon HPC secondo necessità e che Amazon ne abbia abbastanza disponibili.)

Dato che abbiamo 62 ^ 16 possibili password e decifrando il file più piccolo (265B) con gpg prende 0.02s sul mio (piuttosto vecchio) box, la risposta sembra essere "non fattibile" ... Ma esso non fa mai male a chiedere.

Se è preferibile dalle regole del sito, posso riformulare questa domanda come "quanto è difficile interrompere questo metodo di crittografia del backup?" : -)

encryption brute-force pgp

posta Alexander Gladysh 04.06.2012 - 20:27

fonte

1 risposta

Leggi altre domande sui tag encryption brute-force pgp

Alla ricerca di crawler / spider e scanner open source [chiuso] Se i certificati possono essere utilizzati per regolare l'accesso

score 4 · Accepted Answer

Temo che non ci sia niente di meglio della forza bruta. Gli strumenti utilizzati fanno il loro lavoro correttamente o abbastanza vicino.

La duplicazione richiama gpg -c , che per impostazione predefinita esegue la crittografia utilizzando CAST5 con una chiave a 128 bit. Non ci sono grossi attacchi a CAST5 che io conosca.
gpg -c utilizza una funzione di rafforzamento della chiave per generare una chiave simmetrica. Riguarda 2 round ¹⁶ di SHA-1, e dubito strongmente che sia rotto, quindi la vera chiave ha tanto entropia quanto la password che inserisci (circa 95 bit).
pwgen legge un numero casuale a 32 bit da /dev/urandom (che è cripto-quality tranne che a volte su un sistema appena installato che non ha avuto il tempo di generare entropia - e quindi solo se è possibile prevedere la tempistica di tutte le operazioni del disco finora, che è un ordine alto) e prende il resto modulo 62. Non è corretto, perché è inclinato verso le cifre 0123 , ma l'inclinazione è trascurabile (circa 2 ^-30 distribuzione uniforme) per sole 16 serie.
(In realtà c'è un grosso problema in pwgen : viene automaticamente impostato su un generatore casuale non crittografico se /dev/urandom non è disponibile, ma è molto improbabile che tu non abbia /dev/urandom .)

Ogni carattere visualizzato da pwgen viene generato in modo indipendente, quindi non sarà utile avere un'altra password dello stesso batch.

La forza bruta per 2 ⁹⁵ chiavi possibili è fuori questione. Questo è un po 'più di un miliardo di miliardi di miliardi. Dovresti calcolare circa 2 ¹¹⁰ hash SHA-1.

Se la macchina fisica in cui è stato generato il backup è ancora attiva, c'è una possibilità molto piccola che la memoria allocata da pwgen non sia stata riutilizzata da un altro processo. Oppure la memoria allocata dall'emulatore di terminale, o un programma che hai usato per copiare e incollare la chiave, o (ancora più difficile da sfruttare) la memoria allocata da gpg . I tuoi backup potrebbero valere la pena di qualcuno che esamina un dump della memoria.

Controlla se l'output di pwgen potrebbe essere stato registrato da qualche parte. È ancora visibile nella cronologia di un terminale? Esegui regolarmente programmi in script ? È ancora in una sessione di live screen? È nella cronologia degli appunti?

Penso che la soluzione migliore sia tentare il ripristino dell'hardware sul disco guasto.