Quanta maggiore sicurezza ho davvero con una dimensione della chiave più lunga?

6

Immagina di avere un codice che supporta chiavi di 128, 192 o 256 bit. Supponiamo che non vi siano vulnerabilità nel codice, indipendentemente dalla lunghezza della chiave. Lo userò per crittografare qualcosa e userò una password o una passphrase.

Se utilizzo la stessa password, è davvero importante quale sia la dimensione della chiave? Poiché sembra che la bruteforcing di tutte le 2 128 chiavi possibili non sia fattibile nel prevedibile futuro, ho ragione di ritenere che la forza della crittografia sia basata quasi esclusivamente sulla password?

Supponendo che la funzione di derivazione della chiave impieghi lo stesso tempo per generare una chiave di qualsiasi dimensione, non significa che un attacco alla password richiederà la stessa quantità di tempo indipendentemente dalle dimensioni della chiave? Quindi, non è la forza della crittografia molto più una funzione della forza della password rispetto alla dimensione della chiave?

Se il problema persiste, cosa guadagno con una chiave a 256 bit o 192 bit invece di una chiave a 128 bit?

    
posta quantumSoup 19.10.2012 - 22:24
fonte

3 risposte

9

Una volta che hai raggiunto la zona "non può romperlo", aumentare la dimensione della chiave non cambia la sicurezza: non puoi essere più sicuro di così. Una chiave a 128 bit è già nella zona "non può romperlo". Le chiavi più grandi sono per il marketing di persone che hanno bisogno di impressionare gli acquirenti creduloni, e per i militari che devono, per statuto, fare ampie dimostrazioni della loro virilità collettiva.

(I migliori manager di marketing cercano di razionalizzare le dimensioni delle chiavi più grandi parlando dei computer quantistici .)

Se si ricava una chiave da una password e l'estensione della chiave da 128 a 256 bit cambia qualcosa sulla sicurezza, allora lo si sta facendo molto male.

    
risposta data 19.10.2012 - 23:00
fonte
6

Supponendo che non ci siano vulnerabilità nel codice per diverse lunghezze di chiave e che la funzione di derivazione chiave generi output indistinguibili da random, senza collisioni, quindi:

Matematicamente parlando 2 ^ 256 = 2 ^ 128 * 2 ^ 128. L'algebra 2^X in questo caso si riferisce al numero totale di chiavi univoche, chiamato spazio chiave. Poiché ogni bit può essere zero o uno, ci sono due possibilità. Due bit ti danno 2x2, tre 2x2x2 e così via.

Comunque, come ho detto, 2 ^ 256 = 2 ^ 128 * 2 ^ 128 dal 2 ^ 128 * 2 ^ 128 = 2 ^ (128 + 128). Raddoppiando lo spazio degli indirizzi, non hai raddoppiato il numero di possibili chiavi: le hai rese possibili 340282366920938463463374607431768211456 chiavi extra. Se 2 ^ 128 è fuori dalla portata dell'umanità, allora 2 ^ 256 è fuori dalla portata di Skynet.

If I use the same password, does it really matter what the key size is?

Questo dipende dal KDF - PBKDF2, ad esempio, genera blocchi della funzione di hash con chiave fornita come input - e quindi lo alimenta nella successiva iterazione come salt. Pertanto, i primi 160 bit della chiave generata per una chiave a 128 bit sono uguali ai primi 160 bit della chiave generata per una chiave a 256 bit.

La domanda è, allora, questo compromette la chiave? Beh, in realtà non hai alcun valore memorizzato con cui lavorare, per i principianti, ma supponiamo che tu abbia in qualche modo avuto una chiave a 128 bit. Dovresti essere in grado di generare in modo affidabile gli altri 128-bit per generare la chiave a 256-bit, cosa che non puoi fare dall'output a meno che tu abbia l'input. Quindi avresti bisogno di trovare il preimage - la password. Questo potrebbe essere considerato facile, tranne per il fatto che dovresti interrompere comunque molte iterazioni della funzione HMAC che sono state utilizzate.

Un'altra domanda sarebbe è riutilizzabile ? L'implementazione corretta di PBKDF2 utilizza un valore salt, quindi si avrebbe lo stesso problema di come attaccare qualsiasi funzione di hash salata.

isn't the strength of the encryption much more a function of the strength of the password than the key size?

Non proprio. Tuttavia, il problema è che una scarsa tecnica di generazione delle chiavi potrebbe portare a ridurre inavvertitamente le dimensioni dello spazio della chiave, rendendo più facile forzare la password. Ad esempio:

char encryption_key[16] = {0};
strncpy(encryption_key, 16, source);

aes_with_some_mode(encryption_key, plaintext, &ciphertext);

è sbagliato, poiché anche se si assicura che la password sia lunga 16 byte, si è limitato ogni byte a uno di un numero di possibili caratteri e simboli ASCII. Quindi, assumendo solo caratteri maiuscoli, hai ridotto lo spazio della chiave solo a 26 ^ 16. Ti sei appena sparato al piede di un fattore di circa 8 x 10 ^ 15.

I KDF sono progettati per evitare questa situazione (sebbene una fonte veramente casuale sia più ideale) mappando la password allo spazio delle chiavi. Il problema di trovare una chiave corrispondente diventa difficile come trovare un preimage a un algoritmo hash nelle condizioni in cui viene utilizzato nel KDF.

Certamente, con PBKDF2 non sarebbe vero che il KDF impiegherebbe tempo uguale per una chiave a 128 e 256 bit.

    
risposta data 19.10.2012 - 22:31
fonte
6

In parole povere, il problema è nell'ipotesi che hai affermato.

Suppose that there are no vulnerabilities in the cipher regardless of key length.

La sicurezza riguarda difesa in profondità . Proprio come un safecracker non sta andando a sbattere contro una cassastrong con un martello per giorni e giorni, gli aggressori non sono in genere in giro per forzare le chiavi di crittografia brute.

Probabilmente è inevitabile che un giorno un ricercatore della sicurezza scoprirà punti deboli in AES (o qualsiasi altro standard di crittografia simmetrica corrente). La traiettoria probabile è che i punti deboli diventeranno praticamente sfruttabili rispetto ai ciphertexts con chiavi di lunghezza più corta prima, e in seguito saranno estesi (tramite ricerca, hardware specializzato, o semplicemente la legge di Moore) a testi cifrati che usano chiavi più lunghe.

    
risposta data 19.10.2012 - 23:03
fonte