come RC4 è non sicuro e AES-CBC è la stessa cosa, l'unica soluzione è l'utilizzo della modalità EAX per AES. ma perché Mozilla NSS non supporta EAX mod? c'è qualche implementazione EAX sicura? e perché wikipedia dice "utilizzando la modalità CTR significa che la crittografia deve essere implementata solo per la crittografia "?
Non confondiamoci.
RC4 non è totalmente rotto ma il margine di sicurezza è diventato Scomodo piccolo . Sappiamo da anni che RC4 dovrebbe essere sostituito, ma anche che nessuna connessione SSL valida con RC4 è stata interrotta "allo stato selvatico" ancora a causa delle note mancanze di RC4 (gli attacchi sono stati dimostrati in condizioni di laboratorio che sono su il limite di essere realistico, ma non del tutto ancora lì.
AES-CBC non è veramente rotto . Ciò che è stato attaccato (con BEAST) è il modo in cui la modalità CBC viene utilizzata in SSL / TLS . L'effettivo attacco fa non funziona più . Ciò continua a garantire il passaggio a modalità migliori, ma non vi è alcun obbligo assoluto di applicarlo entro la prossima ora; piuttosto, dovremmo promuovere un percorso di transizione nei prossimi anni.
Le buone modalità che dovrebbero essere utilizzate sono le modalità di crittografia autenticate che combinano la crittografia e MAC in modo sicuro. Sono stati definiti molti di questi modi, alcuni dei quali sono (sfortunatamente) coperti da brevetti e altre confusioni di proprietà intellettuale che tendono a rendere delicato il loro utilizzo. I soliti consigli sono EAX e GCM , che sono entrambi privi di brevetti e ragionevolmente efficienti (quando viene data la scelta, di solito preferisco EAX perché funziona meglio su architetture molto piccole, ma GCM va bene, ed è" approvato dal NIST " ). EAX e GCM entrambi internamente usano la modalità CTR, ma questa è solo una parte della storia. Esiste uno standard per le suite di crittografia GCM in TLS, quindi questa è la Via del Futuro: se possibile, prova ad utilizzare il Suite di crittografia GCM nei client e server SSL / TLS. Ma se, per ragioni di usabilità (es. Disponibilità di implementazioni), devi fare affidamento su AES-CBC o anche su RC4, non ti preoccupare troppo: è ancora abbastanza buono per gli standard odierni (è improbabile che anche RC4 essere il punto più debole del tuo server).
La citazione di Wikipedia riguarda una caratteristica tecnica delle implementazioni in modalità CTR: in modalità CTR, il codice a blocchi (l'elemento che elabora un blocco con una determinata chiave) viene sempre utilizzato nei cosiddetti modalità "crittografia", indipendentemente dal fatto che tu usi CTR per crittografare o decrittografare un messaggio. Questo perché la modalità CTR riguarda la generazione di un lungo flusso di byte dipendente dalla chiave; la crittografia dei dati effettiva è un XOR di questo stream con i dati da crittografare e la decrittografia è la stessa operazione . Così si genera sempre il flusso, che esercita sempre il codice a blocchi allo stesso modo. Questa non è una cosa di sicurezza; è una caratteristica che gli implementatori di solito trovano simpatica e conveniente, specialmente su architetture con severi vincoli sulle dimensioni del codice o sull'area del silicio.