Si consiglia di utilizzare OAEP quando i messaggi di riempimento vengono crittografati tramite RSA, per prevenire attacchi di testo normale noti.
Qualcuno può elaborarlo in modo più dettagliato? Mi piacerebbe in particolare conoscere la debolezza dello schema precedente, sia dal punto di vista teorico che pratico / reale.
L'operazione al centro di RSA è un esponenziazione modulare: dato input m , calcolo m e modulo n . Sebbene in generale questa sia una permutazione unidirezionale di interi modulo n , non soddisfa tutte le caratteristiche necessarie per la crittografia asimmetrica generica:
Se e è piccolo e m è piccolo, allora m e potrebbe essere più piccolo di n , a questo punto l'esponenziazione modulare non è più modulare e può essere ripristinata in modo efficiente.
L'operazione è deterministica, che consente una ricerca esaustiva sul messaggio : l'utente malintenzionato crittografa i messaggi possibili finché non viene trovata una corrispondenza con il messaggio crittografato effettivo.
L'esponenziazione modulare è malleabile: data la "crittografia" di m 1 e m 2 , una semplice moltiplicazione produce la crittografia di m 1 m 2 . Questo è simile alla crittografia omomorfica , che può essere una buona proprietà, o meno, a seconda del contesto.
Per questo motivo, il numero intero m soggetto a RSA non deve essere il dato da crittografare da solo, ma dovrebbe essere il risultato di una trasformazione che garantisce che m è "non piccolo", contiene alcuni byte casuali e scoraggia la malleabilità.
Il riempimento "v1.5" in PKCS # 1 svolge il lavoro abbastanza bene, in base a due avvertimenti (noti):
Un motore di decrittografia può essere trasformato in un oracle riempimento se l'utente malintenzionato può inviare messaggi dannosi per decrittografare, e osservare se il motore di decrittografia ha trovato o meno una struttura di imbottitura corretta. Questo è l'attacco di Bleichenbacher, che potrebbe funzionare contro il server SSL, che richiede circa un milione di handshake interrotti per recuperare la chiave simmetrica SSL. I server SSL sono stati successivamente riparati (se la decrittografia non riesce a trovare un padding, il motore continua comunque con un blob casuale invece del "pre-master secret"), ma ciò evidenzia un potenziale problema con PKCS # 1 v1.5.
Questo schema di riempimento non è mai stato "provato". Le prove di sicurezza sono una cosa carina da avere. A mio parere, questa imbottitura ha qualcosa di meglio, che è stato distribuito sul campo e ampiamente utilizzato da quasi 20 anni; ma molte persone lo preferiscono quando ci sono alcune matematiche che confermano l'esperienza.
OAEP mira a migliorare le cose su questi due punti. Si è scoperto che per il riempimento di oracoli, le cose non sono chiare ; e la prima dimostrazione è stata in qualche modo sbagliata da Shoup. La prova è stata "riparata" da Fujisaki, Okamoto, Pointcheval e Stern nel caso di RSA (OAEP è stato progettato come schema di riempimento generico, ma ora abbiamo una prova di sicurezza solo quando usato con RSA).
Per riassumere , OAEP cerca di migliorare rispetto al precedente padding per la resistenza contro attacchi cifratici scelti (non attacco plaintext scelto : poiché il la chiave pubblica è pubblica, chiunque può crittografare qualsiasi cosa a volontà), ma il pad v1.5 era già euristicamente buono, fino a un milione di decrittografie, che è abbastanza buono per molti scopi, e può essere patchato per altri (come è stato fatto per SSL). OAEP fa meglio se implementato correttamente , che non è facile come si crede di solito.
Volevo scavare più a fondo, così ho finito con la lettura di Attacchi di Ciphertext scelti contro i protocolli Basato su RSA Encryption Standard PKCS # 1 di Daniel Bleichenbacher.
Il principale punto debole esiste perché il padding PKCS # 1 ha permesso di formulare alcune ipotesi. Questi presupposti possono quindi essere sfruttati per progettare un attacco. Controlla la carta, è un attacco intelligente! L'attacco è costruito in 4 fasi, ogni fase estraendo progressivamente più informazioni rispetto alla precedente. È altamente iterativo ma nell'ambito della praticità (1 giorno per la tipica chiave di sessione SSL).
Il latching / narrowing per la fase 2-4 è possibile a causa di due motivi:
L'esponenziazione può essere manipolata molto comodamente, specialmente con inversioni di interi in un campo finito. Questa è una proprietà di esponenziazione modulare RSA / stessa - non di per sé riempimento. Ad esempio, una citazione nel documento:
An attacker who wishes to find the decryption m = c^d (mod n) of a ciphertext c can chose a random integer s and ask for the decryption of the innocent-looking message c' = (s^e)*c mod n. From the answer m' = (c')^d, it is easy to recover the original message, because m = m's^−1 (mod n).
Si possono mappare le relazioni matematiche dirette tra il testo cifrato scelto e il risultato della decrittografia sul lato remoto. Questo è omomorfismo dove un'operazione sull'input produce la stessa operazione sull'output. Non si conosce il risultato esatto ma si può dedurre che "Non so quale sia il valore ma ora è 2x il suo valore precedente". Il valore reale stesso viene rilevato mediante il disegno di un intervallo e quindi il restringimento dell'intervallo in modo iterativo.
OAEP cambia un po 'le cose perché aggiunge un po' di hashing (hashing sbilanciato al feistel) tra la decodifica RSA (esponenziazione modulare) e il controllo del riempimento. Questo fondamentalmente interrompe il punto n. 2 sopra e l'attacco non può procedere allo stadio 2-4 perché la conoscenza dallo stadio 1 non può essere passata oltre - l'hashing intermedio di OAEP distorce selvaggiamente la capacità di capire ciò che la parte remota vede su Decodifica OAEP . L'unico modo possibile sarebbe se è possibile invertire in modo deterministico la funzione di hash per procedere con le fasi di raccolta delle informazioni. Ma questo significa che l'hash è rotto.
Quindi RSA è malevole, il che significa che un utente malintenzionato può modificare i messaggi in modo controllato, cioè moltiplicarli per costanti conosciute. Di conseguenza abbiamo bisogno di un qualche tipo di padding per evitare questo: non vogliamo che gli venga chiesto l'autore dell'attacco "Cos'è questo messaggio?" e dargli le informazioni di cui ha bisogno per decifrare un altro messaggio. (Esistono altri attacchi: un sondaggio è link )
È necessario il padding Ergo. Il primo schema di riempimento poneva prima un byte costante, quindi byte diversi da zero, quindi un byte zero e il resto del numero era il messaggio. Sembrava buono.
Sfortunatamente questo implica che un utente malintenzionato può apprendere se il primo byte di rM, M qualsiasi messaggio, qualsiasi numero è una costante costante. Questo risulta essere sufficiente per giustificare la chiave, come mostrato negli anni '90. www.bell-labs.com/user/bleichen/papers/pkcs.ps è la carta.
SSL v3.0 non era sicuro, come lo erano molti altri protocolli implementati, rendendo questo problema piuttosto serio.
Leggi altre domande sui tag cryptography asymmetric