Come posso verificare quale tipo di crittografia in modalità blocco viene utilizzata quando non è disponibile alcun codice sorgente?

Il test per la modalità ECB / CBC / OFB / CTR è abbastanza semplice. È anche semplice vedere se la modalità ha crittografia autenticata come EAX / GCM (anche se non è semplice vedere quale modalità di AE).

• ECB: ha un file con molti blocchi simili nel testo in chiaro. Vedete blocchi identici nel testo cifrato? (Sì, questo è simile alla risposta di Dan, l'ultima parte della risposta di Adnan, ma inclusa per completezza).
• CBC: crittografa un file e quindi capovolgi un bit nell'IV (tipicamente nel primo blocco del testo cifrato); dì che hai capovolto il quinto bit del primo blocco. Vedete un identico bit capovolto nel primo blocco del testo in chiaro dopo la decifratura? Allo stesso modo, capovolgere un bit casuale più avanti nel file dice l'ottavo bit nel decimo blocco del testo cifrato. Quando decifri, vedi il 10 ° blocco senza senso, e poi l'ottavo bit dell'11 ° blocco viene capovolto? Di nuovo, consulta il diagramma modalità di funzionamento per la decrittografia CBC e il motivo dovrebbe essere chiaro.
• OFB / CTR: verifica se hai un codice di streaming. Senza toccare IV / Random Nonce (tipicamente il primo blocco), se si modifica un po 'più avanti nel testo cifrato, si vede lo stesso bit capovolto nel testo in chiaro decrittografato? Se è così, hai un codice stream; una differenza importante da CBC è che in questo caso non c'è un blocco senza senso. Sono d'accordo con il commento di CodesInChaos che c'è poca differenza di sicurezza tra OFB / CTR. Se hai la chiave di crittografia ¹ chiamala K, puoi differenziare OFB / CTR. Ad esempio, lasciare c[1] , c[2] essere il primo e il secondo blocco di testo cifrato e p[1] , p[2] essere il primo blocco di testo in chiaro. Calcola D(K, c[1] XOR p[1]) e D(K, c[2] XOR p[2]) , dove D(K, c) è la decrittografia del blocco c con la chiave K . Se sono numeri consecutivi, hai la modalità CTR. Se D(K, c[2] XOR p[2]) = c[1] XOR p[1] allora hai la modalità OFB.
• EAX / GCM - Entrambe sono crittografate autenticate - contengono un codice di autenticazione dei messaggi (MAC) e il file non decodificherà (nemmeno in caratteri privi di senso) se il file è alterato in quanto il MAC non sarà valido con probabilità schiacciante.

Certo, molti di questi presuppongono cose come la dimensione del blocco, ma dovrebbe essere facile da capire. Ad esempio, crittografare un messaggio molto piccolo (1 byte). Quindi, supponendo che non sia coinvolto MAC, probabilmente creerai un messaggio a due blocchi (IV + un blocco di testo cifrato riempito, anche se CTR / OFB potrebbe non funzionare); quindi crittografare un messaggio più lungo. Da prove ed errori, dovresti essere in grado di scoprire la dimensione del blocco e la dimensione IV.

EDIT: Sono assolutamente d'accordo con l'eccellente punto sollevato da Thomas Pornin. Questo tipo di reverse engineering potrebbe aiutare a scoprire il codice a blocchi, ma in realtà non verifica la sicurezza. Ci sono molte backdoor che potrebbero essere state nascoste in modo che non si possa rilevare senza rovinare l'ingegneria inversa, passando attraverso l'assemblea. Ad esempio, potresti credere di disporre di un codice a blocchi di crittografia autenticato che può essere decodificato solo con la chiave segreta costruita sulla passphrase. Ma in realtà il file è crittografato con una chiave casuale, che è a sua volta crittografata all'inizio del file utilizzando sia la passphrase, e poi una volta con la loro chiave backdoor. Quindi, sarebbero in grado di decifrare qualsiasi file che si usa. O forse lo schema fa questo stesso schema, ad es. All'inizio del file store la chiave per-file da decifrare usando la tua chiave segreta, ma ci sono solo circa un miliardo di chiavi (che le conoscono tutte). O forse è crittografato solo con la tua chiave, ma la funzione di derivazione della chiave utilizza solo i primi ~ 30 bit dell'hash della tua passphrase come chiave. Quindi, potrebbe essere molto rapidamente forzato con un miliardo di tentativi. Allo stesso modo, non deve essere una backdoor deliberata; potrebbe essere solo un'imperfezione impercettibile dell'implementazione, consentendo di eseguire gli ataack del canale laterale.

¹ Questo non è stato presupposto per le altre parti - ci sono molti modi in cui si può sapere di inserire una passphrase nel sistema di decrittografia, ma non si conosce la funzione di derivazione della chiave (o funzione di crittografia) utilizzato internamente per generare la chiave.

@dr jimbob fornisce le risposte corrette per il rilevamento delle modalità di cifratura a blocchi. Vorrei completarlo con un'altra visione della domanda; ovvero: se non puoi sapere quale algoritmo è utilizzato con quale modalità di funzionamento e quale formato, dalla sola documentazione del prodotto, il prodotto non dovrebbe essere utilizzato . In generale, la sicurezza non può essere testata; quindi dobbiamo ricorrere alla prossima cosa migliore, che sta cercando di assicurarci che il prodotto sia stato progettato e implementato con la dovuta attenzione e seguendo le best practice e gli standard stabiliti. Ciò richiede un'ampia documentazione e trasparenza. Una gran parte delle "migliori pratiche" è quella di documentare ciò che fai . Se il prodotto utilizza la crittografia per i tuoi dati ma non dice come funziona, allora sai già che è sub-standard per la parte di documentazione. È quindi più sicuro assumere che il prodotto sia sciatto e non utilizzarlo.

Un altro punto non correlato è che provare a determinare come funzionano le cose all'interno di un dato prodotto costituisce reverse engineering e che potrebbe essere illegale, a seconda del paese in cui vivi e / o lavori. Se è illegale, dovresti astenervi dal farlo e invece insistere sulla documentazione appropriata. Se è legale, alcuni decompilazione o disassemblaggio offrono spesso una visione più precisa di ciò che fa il prodotto, incluso il tipo di algoritmo e la modalità di crittografia. Questo approccio integra i test suggeriti da @dr jimbob.

La BCE, almeno, è facile da rilevare finché puoi richiedere la versione crittografata dei testi in chiaro scelti.

Confronta semplicemente la crittografia di 0000000000000000000000... e 1000000000000000000000... , assicurandoti che i tuoi testi in chiaro siano abbastanza lunghi da coprire alcuni blocchi.

Se ECB è in uso, i testi cifrati differiranno solo nel primo blocco - i blocchi successivi saranno identici. Questo perché ECB crittografa ogni blocco in isolamento. Se è in uso un'altra modalità di propagazione, i due testi cifrati, con alta probabilità, differiranno in tutti i blocchi. Questo perché la differenza nel primo blocco è incorporata nei blocchi successivi.

Tieni presente che non è necessaria la conoscenza della chiave di crittografia per raggiungere questo obiettivo.

Dato che stai cercando la modalità di concatenazione, presumo che tu conosca già l'algoritmo di crittografia e la chiave di crittografia.

La soluzione più semplice che riesco a pensare è quella di definire un testo in chiaro, quindi darlo alla tua black box di crittografia e ottenere il testo cifrato. Quindi scrivi uno script che decodifichi indipendentemente il testo cifrato utilizzando tutto il numero finito di modalità di concatenazione disponibili, quindi confronta il risultato con il testo in chiaro. Qualunque cosa produca una corrispondenza, BINGO!

Un altro modo è definire un testo in chiaro, crittografarlo con tutte le modalità di concatenazione disponibili, quindi confrontare il testo cifrato con l'output della tua casella nera di crittografia per lo stesso testo in chiaro.

L'auditing per la BCE è un po 'più divertente. Definisci il tuo testo in chiaro per avere blocchi identici (blocchi da 16 byte per AES) e guarda l'output per blocchi di testo cifrato identici da 16 byte. Questo metodo non richiede la conoscenza della chiave.