Forum libero

- Scritto da: The Lich
>
> - Scritto da: Rin Kobayashi
> > - Scritto da: The Lich
> > >
> > > - Scritto da: suoranciata
> > > >
> > >
> >
> http://g1.globo.com/English/noticia/2010/06/not-ev
> > >
> > > io mi chiedevo una cosa a propositgo di questi
> > > attacchi basati sul dizionario che alla fine,
> se
> > > non sbaglio, è semplicemente un brute force
> > > raffinato.
> >
> > È un bruteforce limitato a determinate password
> > specifiche, ricavate componendo parole di un
> > dizionario.
> >
> > Testare tutte e 2¹²⁸ combinazioni che se ne
> > escono da una chiave a 128 bit non è fattibile
> > (con NESSUNA potenza di calcolo, nemmeno
> > condivisa fra miliardi di macchine in
> > parallelo).
> > Tuttavia, se con uno stratagemma riesco ad
> > escludere abbastanza chiavi da doverne testare
> > solo 2⁶⁰ (ad esempio), allora si, è fattibile
> ed
> > è proprio così che si
> > fa.
>
> guarda che lo so cosa significa attacco a
> dizionario
>
> > Per questo gran parte della sicurezza sta nel
> > scegliere una password il più casuale possibile,
> > in modo da annientare qualsiasi genere di
> attacco
> > a dizionario.
>
> salvo poi dimenticarsela, più sicura di così...
>
> > Truecrypt in questo senso ha
> > introdotto il concetto di "keyfile", ovvero un
> > file di dati random che entra a far parte della
> > tua password (viene mischiato assieme), così per
> > decrittare il disco oltre alla password che
> > inserisci a mano ti chiede anche di fornirgli
> > questo file. Truecrypt si occupa anche di non
> > alterare i metadati di questo file (data di
> > ultimo accesso ad esempio) in modo da rendere
> più
> > difficile per qualcuno individuarlo nel mezzo di
> > milioni di file dell'utente. L'utilizzo del
> > keyfile rende inutile qualsiasi genere di
> attacco
> > a dizionario (supposto ovviamente che
> > l'attaccante non sappia di questo file e quale
> > esso sia, potrebbe per esempio essere tenuto su
> > una MicroSD nascosta da qualche
> > parte).
> >
> > > Posto che io non conosca il testo in chiaro ma
> > > quanto meno, diciamo, la lingua, il computer
> che
> > > tenta di forzare i dati prova milioni di
> > > combinazioni e ovviamente lì davanti non cì+
> un
> > > operatore che analizzi milioni di documenti
> > > decifrati.
> > > Come si fa a capire SE la password trovata è
> > > quella corretta?
> >
> > Un header Truecrypt (che è cifrato) è formato da
> > 64 byte di salt + 4 byte con la stringa "TRUE"
> > (oltre ai byte che
> > seguono).
> > Se riesci a leggere la scritta "TRUE" alla
> > posizione 64 (partenza da 0) significa che la
> > password che hai dato probabilmente è
> > corretta.
> > L'header poi contiene la password (completamente
> > casuale e indipendente dall'utente) per tutto il
> > resto del
> > disco.
> >
> > > Nel caso di un testo in lingua ci si può
> basare
> > > su analisi della frequenza dei caratteri e
> > > comparsa di parole di uso
> > > comune.
> > > Nel caso di programmi di compressione come
> > winrar
> > > è ancora più semplice, se il testo in chiaro
> non
> > > corrisponde al crc allegato è il programma
> > stesso
> > > che ti dice che la chiave è
> > > sbagliata.
> > > Ma supponiamo che il testo cifrato contenga
> solo
> > > dei codici alfanumerici, come un elenco di
> > numeri
> > > di conto
> > > corrente.
> >
> > Gli IBAN contengono codici di verifica degli
> > errori che permettono ad un programma di testare
> > se tale IBAN è corretto o
> > meno.
> > In altre parole, se decifrando questo file senza
> > header né niente ci trovi un elenco di IBAN
> > validi allora sai che la password data è
> > corretta.
> > Se non c'è modo per fare la verifica allora non
> > puoi nemmeno sapere se la chiave che hai dato
> era
> > o no corretta (per questo Truecrypt include
> > "TRUE" nel suo
> > header).
> >
>
> quindi gira e rigira anche truecrypt fornisce il
> sistema per agevolare la forzatura della
> password.
>
> Metti che non ci sia una stringa true o un crc da
> qualche parte con cui verificare la correttezza
> della password immessa... quanto sarebbe più
> complesso determinare qual è quale giusta con un
> attacco brute
> force?
>
> The Lich™
> « Non è morto ciò che in eterno può
> attendere,
> e col passare di strani eoni, anche la morte può
> morire. »
>
> [img]http://www.gamewyrd.com/previews/bottledimp/i

nel caso di testo potresti passarlo in un normale dizionario e vedere se ci sono parole esistenti. Si potrebbe farlo pure con un binario, dato che sono quasi sempre presenti variabili string con del testo.

>
> quindi gira e rigira anche truecrypt fornisce il
> sistema per agevolare la forzatura della
> password.
>

è il motivo per cui anni fa, quando ho assemblato il mio programmino di cifratura ad-hoc, non c'erano header o indicatori di "correttezza": se sbagliavi password il file risultante era semplicemente illeggibile.

- Scritto da: The Lich
> guarda che lo so cosa significa attacco a
> dizionario

Te l'ho chiarito una volta in più allora.

> salvo poi dimenticarsela, più sicura di
> così...

D'altra parte non si può avere botte piena e moglie ubriaca. Ad ogni modo con i keyfile la password può anche essere "umanamente memorizzabile"... basta che tieni i keyfile ben nascosti (un keyfile può essere un file qualsiasi [un eseguibile, un file di testo, un binario qualsiasi, ecc... meglio cmq se contenente (anche) dati completamente random]).

Il concetto di "sicurezza" viene ad un costo. Non esiste la sicurezza "gratis". Qualcosa devi dare in cambio. Se vuoi una cifratura sicura devi avere una chiave sicura... e questo significa difficile.

Esiste, volendo, questo metodo http://world.std.com/~reinhold/diceware.html per creare password con tot-bit di entropia partendo da parole da un dizionario apposito.
Ma credo che il metodo del keyfile sia alla fine la cosa più sicura e facile da usare.

> quindi gira e rigira anche truecrypt fornisce il
> sistema per agevolare la forzatura della
> password.

No. Dal sapere che a quella posizione c'è la scritta "TRUE" non puoi, in alcun modo, risalire alla chiave (si chiama "known plaintext attack"). È una delle caratteristiche che i cipher moderni devono avere.
Per questo progettare un cipher non è affatto banale, e "farlo in casa" quasi sempre si sbaglia rendendo banale la decodifica. Dietro cipher come AES, Twofish, Serpent, ecc ci sono fior di studi, di prove su prove, di anni di test... non sono inventati a caso, devono soddisfare determinati requisiti minimi.

> Metti che non ci sia una stringa true o un crc da
> qualche parte con cui verificare la correttezza
> della password immessa... quanto sarebbe più
> complesso determinare qual è quale giusta con un
> attacco brute
> force?

Qualsiasi file tu memorizzi, a meno che non si tratti di un file random, avrà una struttura riconoscibile.
Un file JPG, un file EXE, un file di testo semplice, un filesystem... tutti hanno determinate caratteristiche particolari (nel caso dei filesystem ci sono intere aree riservate [dove l'utente non può scrivere] che sono quasi sicuramente sempre a 0 ad esempio).
Se tu prendi un file TXT e lo xori con una password, puoi comunque stabilire che si tratta di un file di testo con una semplice (e veloce) analisi statistica. (Nel caso dello xor banale puoi anche risalire facilmente alla password).

Quindi che senso ha non includere un header quando alla fine il risultato è il medesimo?
Molto meglio avere dei cipher studiati apposta per rendere inutile qualsiasi tentativo di "tornare indietro" dal plaintext alla password.

In pratica, un buon cipher, conoscendo ciphertext e plaintext non deve permettere di scoprire la password.
Vedila come una funzione di hash, tipo SHA-1 ad esempio... puoi andare in una direzione molto facilmente, ma tornare indietro è tutto un altro paio di maniche.

- Scritto da:
> > potrebbe per esempio essere tenuto su
> > una MicroSD nascosta da qualche parte).
>
> E se ti fraccano di botte per sapere dove l'hai
> nascosta?

Puoi dare quella che serve ad accedere al volume che non usi. Truecrypt ha 2 volumi, una pass+keyfile per accedere ad un volume, un'altra pass+keyfile per accedere al secondo volume. Nessuno può dire se esistono 2 volumi oppure uno solo (non è proprio possibile stabilirlo senza la chiave del secondo volume).

In questo modo, se ti minacciano, puoi dare la chiave al volume primario dove non troveranno nulla di che. Avendo la chiave del volume primario non possono sapere se esiste anche un secondario.

> Cioè no, volevo dire... ma a questo punto non
> è meglio xorare e tenere il keyfile su una
> chiavetta nascosta da qualche
> parte?

Lo XOR, a meno che la chiave non sia completamente random e lunga tanto quanto il messaggio, è molto molto facile da rompere.