Apdfpr

[Eymerich (POL)]

Avevo dimenticato la password di un file PDF, così ho comprato la versione pro di Advanced PDF Password Recovery per recuperare i miei documenti. Dato che sapevo che la password era molto lunga e complessa ho optato per un attacco "key search" e non per un brute force. Dopo 4 giorni circa, il programmino mi trova la "ley decription" del file, la applica e mi decritta il documento. Questa "key decription" però (che è di 5 numeri esadecimali), non è la password ma qualcos'altro.
Ora, dato che ho un altra trentina di file criptati con la stessa pwd e per i quali l'applicazione della medesima "key decriprtion" non è valida, devo rifare l'attacco per ognuno dei file (mi ci vorrebbe circa un anno), o c'è un modo per risalire dalla "key decription" o dal file in chiaro alla pwd di criptaggio?
Spero di essere stato chiaro.

Grazie

[ago]

Dipende dal meccanismo di encryption. In alcuni casi le chiavi di encryption/decryption sono legate da una formula matematica. In altri no (es public/private key).

[Eymerich (POL)]

Dipende dal meccanismo di encryption. In alcuni casi le chiavi di encryption/decryption sono legate da una formula matematica. In altri no (es public/private key).

Non so.... Adobe per proteggere i suoi documenti dalla lettura che tipo di sistema di cifratura usa? Il DES?

[ago]

Non so cosa usi adobe, se lo scopri si puo' indagare, gli algoritmi di encryption sono sempre divertenti. Rettifico sopra. Decryption ed encryption key sono sempre legate da un formula matematica, ma in alcuni casi tale formula e' invertibile, in altri no.

[Eymerich (POL)]

Penso che nel mio caso la encription key e la decription key siano uguali. Quello che non riesco a trovare è la password. Mi spiego.
Adobe (le vecchie versioni) cripta i file a 40 bit. 40 bit sono 5 byte, cioè 5 caratteri ( i 5 caratteri esadecimali trovati dal software). La lunghezza della pwd non ha nulla a che vedere con quella della key di criptaggio (o decriptaggio, che nel mio caso è uguale). In pratica il software di criptaggio prende la mia password (che può essere anche di 160 bit o più); questa password non è altro che una lunga stringa di 1 e 0; "piega" questa stringa a metà continuamente sommando o xorando i bit ed eventualmente riempie con degli 0 fino ad arrivare alla lunghezza voluta di 40 bit; l'algoritmo di criptaggio prende questa stringa di 40 bit (la cription key) e la usa per criptare il file. Bisogna vedere, come dici tu, se il processo di "trasformazione" da pwd a cription key è reversibile o no, e come è ricavato. Quello che non mi spiego è come mai, dato che la pwd è uguale, la key sia diversa per ogni file. Probabilmente xora la pwd anche con una stringa casuale del file in chiaro....

[ago]

Comunque DES usa la stessa chiave per encryption e decryption. E' un cifratore simetrico.

Per RSA public/private keys si veda http://www.webkinesia.com/online/os/notes/security.php
Indicando con e l'enctyption key e con d la decryption key, si puo' notare come con RSA non e' possibile ottenere e(d) poiche' oltre a d bisognerebbe conoscere m. Ma m e' un relative prime di d, e siccome per ogni numero ci sono infiniti relative primes non e' possibile ottenere m e quindi e.

[ago]

Quello che non mi spiego è come mai, dato che la pwd è uguale, la key sia diversa per ogni file. Probabilmente xora la pwd anche con una stringa casuale del file in chiaro....

Non ho idea. Ma io non capisco neanche a cosa serva la decryption key a questo punto.

[Eymerich (POL)]

Non ho idea. Ma io non capisco neanche a cosa serva la decryption key a questo punto.

A criptare. La decription key ( che è uguale nel caso di Adobe alla cription key) non è altro che il risultato della funzione hash avente come input la mia pwd.

Vedi ad esempio qui:

Una funzione hash è una trasformazione che dato un ingresso m arbitrario di dimensione variabile, restituisce in uscita una stringa a lunghezza fissa chiamata valore hash h (h=H(m)). Le funzioni hash hanno moltissime applicazioni. Una funzione hash impiegata in crittografia deve essere sicura, i requisiti base cui deve soddisfare sono:

* input di dimensione qualsiasi
* output di dimensione fissa
* H(x) relativamente facile da calcolare per ogni dato x
* H(x) one-way
* H(x) collision-free

Una funzione hash è detta essere one-way se è "difficile" da invertire, ovvero dato un valore h è computazionalmente infattibile determinare x tale che H(x)=h ( è possibile calcolare la funzione in pochi secondi ma calcolare l'inversa può richiedere mesi o anni).

Se dato x è computazionalmente impossibile trovare y diverso da x tale che H(x)=H(y) allora H( ) è debolmente collision-free.

Se è computazionalmente infattibile determinare una qualsiasi coppia x,y tale che H(x)=H(y) allora la funzione hash è fortemente collision-free.

Possiamo pensare al valore hash come ad una rappresentazione concisa del testo più lungo o documento dal quale è stato ricavato applicando la funzione hash.

Una funzione hash key-dependent one-way necessita di una chiave per calcolare e verificare il valore hash. Ciò è utile ad esempio per propositi di autenticazione, una funzione di questo tipo può essere utilizzata dal mittente e ricevente di un messaggio in un meccanismo di tipo challenge-response.

Due processi che sono in possesso della stessa chiave segreta, possono autenticarsi vicendevolmente accordandosi su una sequenza a cui applicare la funzione hash con la chiave e confrontando i risultati ottenuti. Solo nel caso in cui le chiavi segrete siano uguali i risultati saranno identici (essendo H( ) one-way). E il processo può riconoscere il partner. Una funzione key-dependent one-way può essere implementata semplicemente appendendo all'input la chiave e calcolando il valore di una funzione one-way hash.

[Fonte:www.gsmworld.it/crypto.htm]

[ago]

Questo lo so. Quello che intendo e' che non capisco la necessita' di ottenere un hash dalla password in chiaro visto che la password in chiaro puo' essere utilizzata direttamente per criptare il documento. Al piu' potrei capire la necessita' di ridurre la password in chiaro ad un numero fisso di caratteri, ma questo porterebbe sempre allo stesso hash e quindi e' equivalente ad usare la password in chiaro "direttamente". L'utilita' di avere un passaggio intermedio con hash della password non univoche mi sfugge. Anche perche' in questo caso l'encryption/decryption key non e' usata direttamente dagli utenti (diversamente dal meccanismo delle public/private keys).

In ogni caso, se come dici, gli hash della password dipendono dal documento, allora devono utilizzare una caratteristica in comune tra il testo in chiaro e quello criptato. In fase di decriptaggio, come utente tu non conosci direttamente la decryption key, ma solo la passowrd in chiaro. La inserisci e questa viene trasformata in decryption key. Ma se l'encryption key era stata ottenuta mischiando password in chiaro e testo in chiaro, questa volta il programma ha a disposizione solo il testo criptato e la password in chiaro. Quindi per calcolare la decryption key servono caratteristiche "comuni" tra il testo criptato e quello in chiaro. Es il numero di caratteri o porzioni di testo non criptate.

Perche' uno debba fare tutto questo casino invece di utilizzare direttamente la password non lo capisco. Forse perche' craccare l'encryption key e' piu' semplice che non craccare direttamente la password? Ma in questo caso avrebbero potuto usare un hash piu' lungo... O usare "direttamente" la password...

[Eymerich (POL)]

In ogni caso, se come dici, gli hash della password dipendono dal documento, allora devono utilizzare una caratteristica in comune tra il testo in chiaro e quello criptato. In fase di decriptaggio, come utente tu non conosci direttamente la decryption key, ma solo la passowrd in chiaro. La inserisci e questa viene trasformata in decryption key. Ma se l'encryption key era stata ottenuta mischiando password in chiaro e testo in chiaro, questa volta il programma ha a disposizione solo il testo criptato e la password in chiaro. Quindi per calcolare la decryption key servono caratteristiche "comuni" tra il testo criptato e quello in chiaro. Es il numero di caratteri o porzioni di testo non criptate.

E' vero, non ci avevo pensato.

Questo lo so. Quello che intendo e' che non capisco la necessita' di ottenere un hash dalla password in chiaro visto che la password in chiaro puo' essere utilizzata direttamente per criptare il documento. Al piu' potrei capire la necessita' di ridurre la password in chiaro ad un numero fisso di caratteri, ma questo porterebbe sempre allo stesso hash e quindi e' equivalente ad usare la password in chiaro "direttamente". L'utilita' di avere un passaggio intermedio con hash della password non univoche mi sfugge. Anche perche' in questo caso l'encryption/decryption key non e' usata direttamente dagli utenti (diversamente dal meccanismo delle public/private keys).

Perche' uno debba fare tutto questo casino invece di utilizzare direttamente la password non lo capisco. Forse perche' craccare l'encryption key e' piu' semplice che non craccare direttamente la password? Ma in questo caso avrebbero potuto usare un hash piu' lungo... O usare "direttamente" la password...

Non so perchè si scelga di fare così, dipende dall'algoritmo di criptaggio. In genere criptano ad un numero fisso di bit, sono fatti così..... quindi necessitano di trasformare la pwd di lunghezza variabile in una di lunghezza fissa. Bisognerebbe capire perchè hanno scelto di farli in questa maniera.


Comunque il mio problema rimane E, stando a quello che dici, potrebbe essere che i documenti abbiano tutti una pwd diversa