Cosa c'è di sbagliato nell'utilizzare AES direttamente / "raw"?

2

Quando si sviluppano applicazioni che richiedono routine di crittografia, so di usare librerie come keyczar e libsodium piuttosto che le routine di crypto "raw".

Tuttavia, per il caso specifico dell'utilizzo della crittografia simmetrica AES-CBC di un blocco di testo, mi chiedo quali siano le insidie che potrei incappare inconsapevolmente.

(Per un esempio concreto, la prudenza di usare una libreria come questa - che ho letto sopra - è ciò di cui sono stato curioso: link .)

    
posta xyz 05.06.2013 - 10:30
fonte

2 risposte

4

La funzione di cifratura è solo un building block per la crittografia. È importante, senza dubbio, ma è solo un singolo componente che può essere utilizzato sia in modo sicuro che non sicuro. Se scrivi tu stesso il framework crypto e inserisci cifrari, ecc. Dove pensi che vadano, corri un rischio molto reale di fare qualcosa di sbagliato.

Ad esempio:

  • Qual è la tua chiave di crittografia? Stai utilizzando una funzione di derivazione della chiave o semplicemente l'hashing della tua password?
  • Vettore di inizializzazione? Da dove viene e cosa fai con esso?
  • Blocca la modalità concatenamento, che scegli e perché l'hai scelta? Hai detto "CBC perché tutti lo usano"? La tua modalità di concatenamento dei blocchi influisce sulla scelta del vettore di inizializzazione?
  • Autenticazione dei messaggi; stai testando per assicurarti che il messaggio non sia stato manomesso? Dove metti quel codice di autenticazione?
  • Flessibilità: consente di specificare parametri come la specifica di cifratura o la modalità di concatenazione in fase di esecuzione? (Come) indichi la tua decisione nel tuo output?
  • ... e decine di altri problemi che non ti vengono subito in mente.

Ci sono molte decisioni da prendere e un numero enorme di modi per sbagliare. Di solito c'è una risposta facile ma terribilmente sbagliata a ogni domanda alla quale potresti incappare semplicemente non sapendo di dover prendere una decisione.

I quadri (si spera) rispondono a molte di queste domande per te, e (si spera) lo facciano in un modo che sia controllato dalla comunità e in gran parte sicuro. Non tutti i framework fanno le cose nel modo giusto, e molti potrebbero risponderti alla domanda.

Ma (ed ecco il punto importante) se si fa da soli e si costruisce il proprio framework, c'è una probabilità schiacciante che si arrivi alla risposta sbagliata per qualche decisione.

Se utilizzi un framework affidabile, controllato, ben scritto , aumenti le tue probabilità un po '.

    
risposta data 05.06.2013 - 22:27
fonte
1

for the specific case of using AES-CBC symmetric encryption of a block of text

Il problema qui - e con la maggior parte delle implementazioni degli algoritmi crittografici - è che il caso specifico non è sufficientemente specifico. Se stai utilizzando 128 bit di output da / dev / random come chiave, memorizzando quella chiave, quindi inserendola manualmente per crittografare e decifrare, probabilmente sei al sicuro.

Se, tuttavia, non si desidera memorizzare 128 bit veramente casuali, come si ottiene la chiave? Spero che sia una buona funzione di derivazione della chiave basata su password, non un semplice hash crittografico della password e un salt.

Quindi, se non stai attento a quante volte tenterai di decifrare un testo cifrato, avrai bisogno di un codice di autenticazione del messaggio che verifichi l'integrità del testo cifrato prima di tentare la decodifica; o diventerai un oracolo di imbottitura. Thomas Ptacek ha scritto una divertente drammatizzazione di questa modalità di errore: link

Ci sono molti altri attacchi a cui questa applicazione di AES potrebbe essere soggetta, a seconda di come i dettagli reali si concretizzano. Il problema cognitivo sottostante è che noi umani pensiamo formando modelli mentali di situazioni; e i nostri modelli mentali sono, 99.99999% delle volte, non sufficientemente dettagliati e precisi per implementare la crittografia in sicurezza.

    
risposta data 05.06.2013 - 15:31
fonte

Leggi altre domande sui tag