În timp ce NTT analizează acest lucru, postez asta ca o „soluție”:
Prin inspecția funcției
void camelia_setup256(const unsigned char *key, u32 *subkey)
este clar că toate accesele la vectorul de ieșire „subcheie” sunt efectuate folosind macrocomenzi
#define CamelliaSubkeyL(INDEX) (subcheie[(INDEX)*2])
#define CamelliaSubkeyR(INDEX) (subcheie[(INDEX)*2 + 1])
Nicăieri în funcție nu se găsesc referințe la indicii 1 și 33. Acești indici ar scrie în pozițiile cuvintelor 2, 3, 66 și 67. Acestea sunt exact 4 cuvinte în care nu sunt scrise în teste.
Portul OpenSSL al cifrului Camellia (Licența Apache 2.0) nu are această problemă: asamblare și c disponibil.
Actualizați:
Am comparat cele două porturi de mai sus cu codul de la NTT legat în întrebare, după cum urmează:
- generați o cheie aleatorie de 256 de biți
- generează un bloc aleatoriu de 16 octeți
- cu fiecare dintre cele 3 implementări criptați blocul pentru a compara textul cifrat
Rezumat: în ciuda cuvintelor neutilizate din keyTable pentru implementarea NTT, în toate milioanele de perechi cheie/bloc testate, toate textele cifrate generate de cele 3 implementări s-au potrivit.
Remediere:
Deoarece nu afectează criptarea/decriptarea, remedierea reduce doar dimensiunea keyTable de la 68 la 64 de cuvinte.Deoarece codul este foarte curat și toate accesările sunt efectuate cu cele două macrocomenzi de mai sus, trebuie schimbate doar 16 linii (testat doar cu chei de 256 de biți):
- Găsiți toate macrocomenzile care accesează indexul 24 și schimbați-l la 1
- Găsiți toate macrocomenzile care accesează indexul 32 și schimbați-l la 24
Am testat acest lucru în procesul descris mai sus.
