diff options
| author | Kévin Le Gouguec <kevin.legouguec@airbus.com> | 2019-06-12 17:34:41 +0200 |
|---|---|---|
| committer | Kévin Le Gouguec <kevin.legouguec@airbus.com> | 2019-07-05 11:13:26 +0200 |
| commit | 12fb79910fd7072571e9de1e5c34353d564bc047 (patch) | |
| tree | 77bdd81f6338625b71d0df1dd1534b6404b84fe6 /src/add_tweakeyloop/cipher.h | |
| parent | 904b99b495a419fefc666e489c31893f86d5080e (diff) | |
| download | lilliput-ae-implem-12fb79910fd7072571e9de1e5c34353d564bc047.tar.xz | |
Changement de la concaténation des chaînes de bits
L'implémentation précédente n'était pas cohérente. Étant données deux
chaînes X et Y de longueur x et y, et Z=X∥Y de longueur z=x+y,
- pad10* et la construction des tweaks fonctionnaient selon la logique
"indices faibles = LSB", donc
Z[0] = Y[0]
Z[z-1] = X[x-1]
- le découpage de M, C et A en blocs fonctionnait selon la logique
"indices faibles = premiers blocs", donc
Z[0] = X[0]
Z[z-1] = Y[y-1]
En conséquence, la façon dont M, C et A étaient paddés n'avait aucun
sens, e.g. pour un message M de taille 35, pad10*(M*) donnait :
{ M[34], M[33], M[32], 0b10000000, 0, … }
Les deux seules façons logiques de padder M* sont
{ M[32], M[33], M[34], 0b10000000, 0, … }
ou
{ M[2], M[1], M[0], 0b10000000, 0, … }
Après revue d'autres implémentations de ΘCB3 et SCT-2, j'ai choisi de
suivre la convention MSB. En conséquence, quand la spécification dit
Z = X∥Y
L'implémentation traduira :
Z[] = { X[0], … X[x-1], Y[0], … Y[y-1] }
Dans la même logique, les compteurs de blocs seront insérés MSB
d'abord et paddés en conséquence, e.g.
j=0x01020304 ≡ J[] = { 0, …, 0x01, 0x02, 0x03, 0x04 }
Diffstat (limited to 'src/add_tweakeyloop/cipher.h')
0 files changed, 0 insertions, 0 deletions
