| Age | Commit message (Collapse) | Author |
|
De façon à ce que d'autres versions puissent réutiliser l'un ou
l'autre.
|
|
1. Ça ressemble plus à ce qu'on voit sur le schéma.
2. Pour une raison obscure, la version incrémentée bouffe souvent plus
de ROM et plus de cycles (jusqu'à 5% de ROM sur ARM).
|
|
Problème introduit par 4aa9eec.
|
|
Changements mineurs :
- remplacement du tableau intermédiaire F par une fonction,
- réécriture de la couche linéaire avec des boucles.
Le but est d'améliorer la lisibilité par rapport à la spécification,
tout en limitant les différences avec la version "felicsref".
|
|
Pour aider à l'implémentation VHDL.
|
|
Ajout du nonce dans le tweak une bonne fois pour toute
à l'initialisation de l'algorithme, au lieu de le rajouter à chaque
tour de boucle.
Similaire à notre implémentation de SCT-2, et à l'implémentation de
référence de Deoxys-I.
|
|
|
|
Bug introduit par 3bb63d9.
|
|
Surtout par souci d'homogénéité.
|
|
- "block number" → "block index"
- "192" → "t"
- boucle de copie de l'index
- utilisation de size_t :
- par définition, aucune implémentation ne pourra traiter plus
d'octets que SIZE_MAX (donc pas plus de blocs),
- pas de raison de forcer un index de 64 bits sur ces pauvres
ATmega et MSP430.
|
|
SOUMISSION_NIST/REFERENCE_IMPLEMENTATION/src/add_vhdltbc/decrypt/crypt_pack.vhd, SOUMISSION_NIST/REFERENCE_IMPLEMENTATION/src/add_vhdltbc/decrypt/top.vhd, SOUMISSION_NIST/REFERENCE_IMPLEMENTATION/src/add_vhdltbc/encrypt/crypt_pack.vhd files
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hopefully, le résultat est plus clair en construisant le tweak par
concaténations progressives.
|
|
|
|
|
|
Et petits nettoyages par-ci par-là.
|
|
Le code résultant ressemble plus à ce qui est décrit dans les
algorithmes 3 et 4.
|
|
Très similaire à ae_common._tweak_associated_data.
|
|
|
|
|
|
|
|
|
|
|
|
Et réutilisation de fonctions Python natives.
|
|
IME, itérer sur un range() est rarement la façon la plus expressive de
faire les choses ; les alternatives imposent une structure qui rendent
l'intention plus claire. E.g. quand on voit une compréhension, on
comprend que l'auteur cherche à filtrer et/ou transformer ce sur quoi
il itère.
Réutilisation de xor_state(), renommé xor() puisqu'il sert dans
plusieurs situations.
Séparation de ce xor() et des fonctions communes aux modes
authentifiés pour éviter un import circulaire.
|
|
Surtout la capitalisation des noms de fonction.
Retrait des lignes de '#' ; si il y a des séparations à faire, autant
ajouter des modules.
Correction de _MessageTweak.BLOCK en passant.
|
|
|
|
On bénéficie déjà de l'espace de nommage "lilliput".
|
|
Idem, renommage des fonctions privées avec un souligné pour que l'API
soit plus simple à comprendre.
⚠ Pas testé, ça prend littéralement 20 minutes à l'implémentation
Python de générer les vecteurs de test, et c'est l'heure du dodo…
|
|
Ajout d'un souligné devant les fonctions privées ; de cette façon,
>>> from lilliput import lilliput_ae_1
>>> help(lilliput_ae_1)
… ne montre que les fonctions "publiques", i.e. celles que
l'utilisateur est censé appeler.
|
|
|
|
Et ajout d'un métascript pour vérifier la conformité.
Il ne reste plus qu'à… (bis)
|
|
Pas besoin de la condition. Ajout d'un exemple.
|
|
Semblable en tout point à l'implémentation de référence, sauf pour des
optimisations manuelles dans tweakey.c.
Les gains sont significatifs même si surprenants :
Lilliput-I-128 on AVR (vref with -O3)
code_size: -3.21% (7420 ↘ 7182)
code_ram: -2.08% (530 ↘ 519)
code_time: -26.13% (176922 ↘ 130701)
Lilliput-I-192 on AVR (vref with -O3)
code_size: -3.66% (7550 ↘ 7274)
code_ram: -1.90% (578 ↘ 567)
code_time: -28.34% (228210 ↘ 163530)
Lilliput-I-256 on AVR (vref with -O3)
code_size: -4.05% (7698 ↘ 7386)
code_ram: -1.71% (642 ↘ 631)
code_time: -29.87% (301863 ↘ 211704)
Lilliput-II-128 on AVR (vref with -O3)
code_size: -3.04% (6704 ↘ 6500)
code_ram: -2.94% (511 ↘ 496)
code_time: -25.97% (181884 ↘ 134648)
Lilliput-II-192 on AVR (vref with -O3)
code_size: -3.56% (6682 ↘ 6444)
code_ram: -1.97% (559 ↘ 548)
code_time: -26.30% (264608 ↘ 195028)
Lilliput-II-256 on AVR (vref with -O3)
code_size: -4.06% (6804 ↘ 6528)
code_ram: -1.77% (623 ↘ 612)
code_time: -28.47% (354220 ↘ 253368)
Lilliput-I-128 on MSP (vref with -O3)
code_time: -17.72% (153285 ↘ 126129)
Lilliput-I-192 on MSP (vref with -O3)
code_size: -1.02% (8466 ↘ 8380)
code_time: -19.77% (199203 ↘ 159828)
Lilliput-I-256 on MSP (vref with -O3)
code_time: -20.90% (268416 ↘ 212328)
Lilliput-II-128 on MSP (vref with -O3)
code_size: -2.49% (6336 ↘ 6178)
code_time: -13.25% (172179 ↘ 149363)
Lilliput-II-192 on MSP (vref with -O3)
code_size: -1.22% (6406 ↘ 6328)
code_time: -17.93% (227943 ↘ 187063)
Lilliput-II-256 on MSP (vref with -O3)
code_size: -1.30% (6600 ↘ 6514)
code_time: -19.98% (307751 ↘ 246251)
Lilliput-I-128 on ARM (vref with -O3)
code_time: -16.94% (104944 ↘ 87170)
Lilliput-I-192 on ARM (vref with -O3)
code_time: -18.41% (132736 ↘ 108295)
Lilliput-I-256 on ARM (vref with -O3)
code_time: -18.74% (175979 ↘ 143001)
Lilliput-II-128 on ARM (vref with -O3)
code_time: -17.63% (114004 ↘ 93907)
Lilliput-II-192 on ARM (vref with -O3)
code_time: -17.55% (157405 ↘ 129780)
Lilliput-II-256 on ARM (vref with -O3)
code_time: -18.44% (206440 ↘ 168382)
Lilliput-I-128 on PC (vref with -O3)
code_time: -11.43% (11744 ↘ 10402)
Lilliput-I-192 on PC (vref with -O3)
code_time: -10.54% (14593 ↘ 13055)
Lilliput-I-256 on PC (vref with -O3)
code_time: -11.80% (18856 ↘ 16631)
Lilliput-II-128 on PC (vref with -O3)
code_size: -1.02% (7421 ↘ 7345)
code_time: -9.11% (13080 ↘ 11889)
Lilliput-II-192 on PC (vref with -O3)
code_time: -10.51% (16809 ↘ 15043)
Lilliput-II-256 on PC (vref with -O3)
code_time: -10.96% (21970 ↘ 19561)
|
|
… En vrai je ne vois pas de bonne raison de se soucier des espaces en
bout de ligne. Les outils de diff savent les ignorer, les éditeurs
savent les ignorer…
🤷
|
|
|
|
L'implémentation de référence se basait sur les indices figurant dans
le papier de Deoxys. Deux questions à résoudre, que d'autres se sont
sans doute déjà posées :
- Est-ce que ce l-1 est normal dans le papier de Deoxys ?
- Est-ce que nos changements d'indices sont bien tous corrects ?
En tout cas, les implémentations Python et C sont maintenant d'accord.
|
|
Ça m'embêtait qu'on liste plusieurs personnes, puis qu'on dise "the
implementer has…" ; repompé le "hereby denoted…" de Keccak.
|
|
Un peu de machinerie à mettre en place pour permettre l'ajout de
fichiers arbitraires dans une implémentation.
|
|
- retrait de stdio.h (inutile)
- "aération" du prototype de _state_init
|
|
- fins de ligne UNIX (\n)
- espaces plutôt que tabulations
|
|
Dans le but de rendre
diff -ru ref add_threshold
plus digeste.
|
|
- ordre alphabétique des auteurs,
- un auteur par ligne, date sur une ligne séparée : maintenance et
diff plus simples,
- brève description de chaque fichier.
|
|
Modifications nécessaires dans l'infra :
- retrait conditionnel de test-tweakey, vu que l'API n'est pas la même
pour l'implémentation à seuil,
- retrait conditionnel de l'avertissement "-Wparentheses", plus
agaçant qu'autre chose sur les calculs booléens de cipher.c, e.g.
y_hi&3 ^ (y_hi&8)>>1
où la priorité est intuitive (shifts avant AND avant XOR). C'est
dommage de perdre les avertissements sur if (a&b == c), mais tant
pis… On va compter sur La Suite De Test®©™ pour nous couvrir.
Co-authored-by: Alexandre Adomnicai <a.adomnicai@trusted-objects.com>
Co-authored-by: leo <leo.reynaud17@gmail.com>
|
|
|