Questo utilizzo di AES-CBC è pericoloso

Question

Questo utilizzo di AES-CBC è pericoloso

#1 da (4 voti)

1

Immagina che un utente malintenzionato sappia:

Un testo cifrato corretto
L'algoritmo: AES-256-CBC.
L'implementazione: openssl CLI.
IV.
HMAC-SHA-256 del testo cifrato.

Ma non conosce la chiave (supponiamo che la chiave sia stata scelta in modo sensato e che non sia derivata, ma piena a 256-bit). Inoltre, questo è l'unico testo cifrato associato a questa chiave.

Nessun server. È abbastanza per essere vulnerabile all'attacco oracle? Significato: un utente malintenzionato può ottenere il testo in chiaro?

cryptography attacks attack-prevention aes

posta Randolph 07.04.2018 - 18:51

fonte

1 risposta

Leggi altre domande sui tag cryptography attacks attack-prevention aes

Quali sono i vantaggi di registrare il nome utente di un tentativo di autenticazione fallito? Port forwarding per reverse tcp

score 4 · Accepted Answer

Un "oracle padding" è un'entità (di solito una sorta di server) che decodifica un messaggio arbitrario, verifica se il padding è corretto e restituisce queste informazioni al submitter (arbitrario) del messaggio. Se nel tuo schema non esiste un'entità di questo tipo, non puoi avere un attacco di oracolo con padding , in quanto non esiste un oracle di riempimento da utilizzare per l'attacco.

Altri punti rilevanti:

Non si specifica uno schema di riempimento che si sta utilizzando. In pratica il comando openssl utilizzerà PKCS # 5, che è uno schema di riempimento che può essere utilizzato per rilevare la manomissione banale del testo cifrato (sebbene non sia affidabile in questo) ed è quindi applicabile per un attacco oracle di padding, ma altri schemi di padding potrebbero non avere questa proprietà, nel qual caso esiste persino un oracle di riempimento.
Hai menzionato un HMAC, ma non come viene usato. Si dice che è l'HMAC del testo cifrato, il che significa che la verifica deve essere eseguita anche rispetto al testo cifrato. In pratica, questo significa quasi sempre che la verifica viene eseguita prima della decrittazione. Dal momento che l'HMAC fallirà la verifica, si spera che l'elaborazione del testo cifrato si fermi prima di arrivare alla decrittazione (che viene prima di poter controllare il riempimento). In uno scenario del genere, anche se si avesse un oracle di riempimento un messaggio modificato non lo raggiungerà mai, perché fallirebbe al controllo HMAC. (Si noti che gli HMAC del testo in chiaro, che ovviamente non possono essere verificati fino a dopo la decifrazione, non hanno questa proprietà, sono molto più suscettibili di essere vulnerabili a un attacco oracle di riempimento).