RC2 è un codice a blocchi attualmente "ininterrotto"; l'attacco più noto è un "attacco a chiave correlata", cioè qualcosa che non si applica in pratica (gli attacchi a chiave correlata riguardano proprietà specifiche quando la vittima usa due chiavi distinte, che l'attaccante non conosce, ma con una differenza tra loro che l'attaccante sa).
RC2 ha ancora alcune proprietà sub-ottimali:
-
Utilizza blocchi a 64 bit. Questo rende inadatto all'elaborazione di grandi insiemi di dati, essendo il cut-off attorno a 2 blocchi n / 2 quando i blocchi consistono in bit n . Per un cifrario a 64 bit, questo ammonta a circa 30 gigabyte con una sola chiave, che è grande ma non irraggiungibile in alcuni contesti. Crittografare più dati di quelli implica il rischio di rivelare parte del testo in chiaro. Si noti che 3DES soffre esattamente della stessa limitazione. Per le email crittografate, dovresti accettarlo.
-
Le sue prestazioni fanno schifo. Circa tanto quanto quello di 3DES; sul mio laptop (sottodimensionato), l'implementazione di OpenSSL raggiunge circa 10 MB / s con 3DES, 12 MB / s con RC2. Anche in questo caso, per le e-mail, questo non dovrebbe essere un problema.
-
RC2, nella sua descrizione, utilizza molte tabelle di ricerca dipendenti dai dati. In questo senso, sarebbe molto difficile realizzare un'implementazione che è "tempo costante" (cioè non perde informazioni agli aggressori che possono eseguire il proprio codice sullo stesso hardware, attraverso differenze temporali indotte dalla cache); almeno, sarebbe molto difficile crearne uno senza un enorme rallentamento (come un fattore di rallentamento di 100x). Nota che le classiche implementazioni 3DES non sono neanche costanti, ma ciò può essere fatto solo con un rallentamento "moderato" (relativamente di circa 3,5x con il mio codice).
Poiché l'invio di e-mail è asincrono e inoltre, poiché la crittografia e la decifratura delle e-mail tendono a verificarsi sul computer desktop dell'utente, non su un server condiviso, questo tipo di perdita di canale laterale non dovrebbe comunque costituire una grande preoccupazione. A meno che non decidiate di caricare le chiavi private su un server, nel qual caso i dubbi potrebbero tornare - assicuratevi, almeno, che il server non sia ospitato in una nuvola che condivide lo stesso hardware con gli estranei.
-
RC2 ha una lunghezza della chiave configurabile, compresa tra 1 e 128 byte (vale a dire da 8 a 1024 bit e multipli di 8). Pertanto, sebbene RC2 possa essere un algoritmo sufficientemente tollerante, può comunque essere utilizzato con una chiave troppo breve per garantire un livello di sicurezza accettabile. RC2 include anche un parametro aggiuntivo (chiamato "lunghezza della chiave efficace") che può essere utilizzato per limitare la resistenza a forza bruta. Storicamente, RC2 è stato molto utilizzato in configurazioni intese a rispettare le regole di esportazione crittografiche statunitensi precedenti al 2000, con una forza tipica equivalente a 40 bit (cioè non strong affatto).
Il quarto punto è, a mio avviso, il più grande rischio quando si utilizza RC2. Non sai davvero quanto sia grande la vera chiave di crittografia; se il software che usi non documenta tali informazioni, allora non sai quanto sarà strong la crittografia. Inoltre, il software che usa RC2 potrebbe essere un po 'carente nella manutenzione ...
Per riassumere, non c'è niente di veramente sbagliato in RC2 stesso per la crittografia delle email, ma l'implementazione ha ancora ampio spazio per fare cose stupide che annientano la sicurezza.