Ci sono problemi con l'utilizzo di suite di crittografia basate su CAMELIA, IDEA e SEED su un server web nel 2016?

In generale, mi auguro che tutte le suite di cifratura moderne supportino le modalità moderne (in questo momento, in genere GCM o CCM, con la sola possibilità che GCM diventi ampiamente disponibile finora).

Ciò consentirà di mitigare le future debolezze algoritmiche (come il progressivo indebolimento di RC4) disabilitando il noto cifrario debole pur avendo ancora cifrari ancora forti, già ampiamente diffusi. Avere una varietà di opzioni valide e solide è fondamentale quando si trovano difetti in uno di essi.

IDEA è antico, a 64 bit, e dovrebbe essere deprecato per RFC5469 come hai notato. Lo raccomanderei mai più usato.

CAMELLIA è un codice moderno accettato dal progetto europeo NESSIE nel suo selezione finale di algoritmi insieme ad altri tre codici a blocchi (incluso AES).

CAMELLIA è anche accettata dal progetto giapponese CRYPTREC nel suo Specifiche di crittografie consigliate per l'e-government .

Consiglierei di supportare pienamente CAMELLIA in modalità GCM per RFC6367 .

SEED è un vecchio cifrario sudcoreano; Non consiglierei di supportarlo, soprattutto perché non sono a conoscenza di GCM o di altre modalità moderne disponibili in TLS; solo le vecchie modalità in RFC4162 .

Il più moderno codice sudcoreano è ARIA ( RFC5469 ). ARIA ha aggiunto diverse suite di crittografia a TLS in RFC6209 , comprese le suite in modalità GCM che sono degne di considerazione.

IDEA utilizza blocchi a 64 bit. Ciò significa che inizia a creare problemi, crittograficamente parlando, se si crittografa più di 2 ³² blocchi di dati con la stessa chiave (in modalità CBC). Questo è 32 gigabyte, che è abbastanza grande, ma non irraggiungibile per gli standard odierni. Quindi, dovrebbe essere evitato.

Camelia e SEED sono codici a blocchi che esistono soprattutto perché i governi giapponese e coreano soffrono di sindrome NIH . Per quanto ne sappiamo, sono algoritmi abbastanza decenti, proprio come l'AES. Non c'è una ragione sostanziale per credere che siano più forti; se sei dal lato paranoico, considera che se esiste un metodo sconosciuto con cui l'AES potrebbe essere spiked, quindi non c'è motivo di credere che Camellia e SEED non siano ugualmente influenzati.

Un motivo pratico per preferire AES è che c'è stato molto più lavoro per realizzare implementazioni a tempo costante di AES. Inoltre, alcune CPU offrono un supporto hardware, che è ancora migliore per la protezione dagli attacchi dei canali laterali e offre prestazioni migliori. Un tipico server Web non presenterà problemi di prestazioni con nessuno di questi algoritmi; se gli attacchi dei canali laterali sono applicabili nella pratica o meno è ipotizzabile da chiunque.

Ancora sul lato pratico delle cose, se i client non supportano Camellia o SEED, allora è piuttosto inutile abilitarli sul server - non saranno comunque utilizzati.

Non vedo un motivo per favorire, ad es. AES rispetto ad altri cifrari ben testati. Anche se IDEA e altri cifrari potrebbero non avere tante ricerche in corso sulla loro sicurezza, non saranno mai testati.

Penso che il problema più grande sarebbe che viene utilizzata una versione precedente di TLS (o anche SSL precedente). La superficie di attacco creata da questo e in aggiunta ai bug delle versioni precedenti di OpenSSL è molto più grande.

Quindi secondo me (non sono un crittografo o un esperto di sicurezza) l'uso di cifrari ben testati che non sono molto popolari non è un problema. Tuttavia, non aumenta la sicurezza, quindi non vi è alcun motivo particolare per cui si desideri utilizzare cifrature esotiche.