summaryrefslogtreecommitdiff
path: root/src/add_vhdltbc/decrypt/crypt_pack.vhd
diff options
context:
space:
mode:
authorKévin Le Gouguec <kevin.legouguec@airbus.com>2019-06-12 17:34:41 +0200
committerKévin Le Gouguec <kevin.legouguec@airbus.com>2019-07-05 11:13:26 +0200
commit12fb79910fd7072571e9de1e5c34353d564bc047 (patch)
tree77bdd81f6338625b71d0df1dd1534b6404b84fe6 /src/add_vhdltbc/decrypt/crypt_pack.vhd
parent904b99b495a419fefc666e489c31893f86d5080e (diff)
downloadlilliput-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_vhdltbc/decrypt/crypt_pack.vhd')
0 files changed, 0 insertions, 0 deletions