Data Encryption Standard (Wikipedia)
So che con la forza bruta ci sono 2 ^ 56 possibili chiavi da controllare (56 bit, ognuno dei quali è 1 o 0). Ma diciamo che so che il messaggio stesso è composto solo da lettere (a-z, A-Z).
La conoscenza delle cose (come la limitazione alle sole lettere) sul testo in chiaro rende più semplice rompere la crittografia?
In una ricerca di forza bruta standard si presume che tu conosca almeno un testo in chiaro e la relativa crittografia associata a una determinata chiave. Quindi il fatto che il testo in chiaro provenga da un set limitato non ti aiuterà, a meno che non ci sia qualche altra debolezza che stai sfruttando.
Affinché un attacco di forza bruta abbia effettivamente successo (anche in modo teorico), l'attaccante deve sapere "qualcosa" sul testo in chiaro, per sapere se ha trovato o meno la chiave giusta. Detto altrimenti: se tutto l'hacker sa del testo in chiaro è che è un mucchio di byte casuali, quindi, per ogni chiave provata, è esattamente quello che otterrà: un mucchio di byte dall'aspetto casuale.
D'altra parte, se l'attaccante ha trovato utile attaccare il sistema (perché una ricerca esaustiva 2 56 è, anche se fattibile, piuttosto costosa), allora deve avere una conoscenza a priori di ciò che troverà. Questo può essere qualsiasi cosa come un formato standard (ad esempio, i dati sono XML, a partire da un'intestazione XML, oppure i dati sono compressi con gzip e quindi inizia con un'intestazione gzip ) o anche alcune informazioni di base come "il testo in chiaro è un testo che 'ha senso' ".
Il testo inglese con codifica ASCII utilizzerà solo alcuni valori di byte, vale a dire valori di byte da 32 a 126 (inclusi), ed eventualmente anche 9 (tabulazione orizzontale), 10 e 13 (LF e CR, rispettivamente, per fine linee), 12 (tabulazione verticale), e possibilmente 26 (fine del file su sistemi DOS / Windows). Quindi questo è 100 su 255 possibili valori di byte. Una decrittografia di un singolo blocco DES (8 byte) con una chiave errata ha una probabilità su (100/255) 8 di consistere solo in questo insieme di "caratteri plausibili". Poiché l'utente malintenzionato ha 2 chiavi 56 da provare, deve decrittografare i blocchi n in modo che la probabilità di accettare una chiave errata non sia superiore a 2 -56 . Questo viene ottenuto non appena n = 6 (perché (100/255) 8 * 6 & leq; 2 -56 ). Questo porta ad un esauriente attacco di ricerca in cui l'attaccante decrittografa i blocchi 6 per chiave potenziale, filtrando le chiavi sbagliate osservando i caratteri ottenuti.
Ora, diciamocelo, "8g;; = 7Zf" non è esattamente "testo che abbia senso". Quindi l'hacker conosce molto più di quanto "il testo in chiaro consiste solo in caratteri ASCII stampabili". Poteva filtrare la decrittazione sbagliata che produce solo caratteri stampabili ma non brani di testo plausibili. Potrebbe anche ottenere, diciamo, un migliaio di "chiavi possibili" (ciascuna che produce qualcosa che, dal punto di vista di un computer, è testo-con-senso-simile) e finisce il lavoro a mano (il cervello umano è molto buono per individuare il testo reale tra una lista di caratteri dall'aspetto gibberesco). Quindi un utente malintenzionato potrebbe usare, ad esempio, due o tre blocchi e continuare a fare le cose.
È molto difficile quantificare l'efficienza dell'attaccante nel filtrare la decifrazione errata, perché dipende da ciò che l'hacker "indovina", qualcosa che è nel regno della psicologia, non del computer scienza. Pertanto, gli accademici usano la "convenzione sicura" di considerare che l'attaccante ha un blocco di testo in chiaro noto: sa con certezza al 100% un testo in chiaro a 8 byte per il quale ha anche il testo cifrato corrispondente. Questo potrebbe non essere vero in una situazione di attacco reale, ma non puoi davvero prevederlo.
Dipenderà da come si controlla ciascun tasto. Se inizi a 0 e continui ad aumentare, dovrai convertire il set di caratteri e verificare se quel carattere è valido. Oppure puoi lavorare nell'altro modo, iniziare con un personaggio e solo incrementare di un personaggio all'interno del set.
Penso che se incrementassi per carattere invece che per bit, avresti un set di lavoro molto più piccolo e quindi ci vorrebbe meno tempo per scorrere tutte le combinazioni.
Sapere che le soluzioni possibili appartengono a un set limitato ti aiuterà perché puoi terminare presto il processo di decrittografia.
Nel tuo caso puoi decifrare solo una quantità limitata di testo cifrato / cifrato (i primi 8/16 / ... byte per esempio) e salvare per un giro successivo solo i testi decrittografati / semplici che sono composti solo da lettere (az, AZ). Successivamente puoi aumentare la quantità decrittografata se lo spazio delle soluzioni salvate è troppo grande o semplicemente esaminarle tutte e decidere quale è giusto.
La risposta breve è "teoricamente sì" .
Ma: non è questa la ragione principale per cui DES è inciampata sui propri piedi.
Lascia che ti dia un po 'più informazioni ...
Al giorno d'oggi, DES è considerato insicuro per la maggior parte delle applicazioni. Ciò è causato principalmente dal fatto che la dimensione della chiave a 56 bit è troppo piccola. Ciò significa che diventa ovvio quando sai che nel gennaio 1999, "Electronic Frontier Foundation" e "distributed.net" hanno collaborato per rompere con successo un tasto DES in 22 ore e 15 minuti ... pubblicamente.
Le dimensioni ridotte della chiave erano uno dei motivi per cui il DES è stato ritirato come standard dall'Istituto nazionale degli standard e della tecnologia.
Ma: si ritiene che l'algoritmo sia praticamente sicuro sotto forma di Triple DES, sebbene vi siano attacchi teorici. Negli anni più recenti, il codice è stato sostituito dall'Advanced Encryption Standard (AES).
I miei 2 centesimi: "Se puoi evitare DES, evita DES!"
Leggi altre domande sui tag cryptography encryption cryptanalysis