| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
De sorte à ce qu'on puisse le lancer depuis n'importe quel dossier.
|
|
|
|
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.
|
|
Idéalement, il faudrait rajouter les bonnes dépendances dans le
Makefile…
|
|
|
|
|
|
En plus du paquet Python "lilliput", chaque dossier embarque
- un script "genkat_aead.py" qui génère les vecteurs de test via l'API
du module "crypto_aead",
- un module "crypto_aead" servant de point d'entrée générique,
- un module "parameters", qui permet à crypto_aead d'instancier
Lilliput-AE avec le bon mode et la bonne taille de clé.
Livraison dans ./crypto_aead sans se soucier de l'arborescence du
dépôt, par homogénéité avec make-package.sh.
Quelques ajustement dans genkat_aead.py pour que le lien avec
genkat_aead.c soit plus évident.
|
|
|
|
Et ajout d'un métascript pour vérifier la conformité.
Il ne reste plus qu'à… (bis)
|
|
Pour aider l'implémentation matérielle.
|
|
Il ne reste plus qu'à générer les dossiers lilliputae*/add_python et
les fichiers parameters.py correspondants, et on peut ajouter le tout
à l'archive à soumettre au NIST.
|
|
|
|
Quand le tout sera packagé sous le namespace "lilliput", le préfixe
alourdira plus qu'autre chose.
|
|
Pas besoin de la condition. Ajout d'un exemple.
|
|
Dans le cadre d'une croisade contre les range(len(…)).
Suppression d'un paramètre inutile dans la foulée.
|
|
Plutôt que int() ; moins de bruit.
… Au passage, simplification (j'espère) de ArrayToBlockbytesMatrix() :
- pas besoin d'initialiser la matrice à zéro ; suffit d'ajouter les
octets et les blocs comme ils viennent,
- AFAICT,
int((length + (BLOCK_BYTES - (length % BLOCK_BYTES))) / BLOCK_BYTES)
quand length % BLOCK_BYTES > 0, c'est juste une façon compliquée
d'écrire
int(length/BLOCK_BYTES) + 1
|
|
- espaces avant ':'
- espaces en trop après ','
- parenthèses dans les if
- levée d'exception plutôt que 'return None' implicite
Simplification de genkat_aead.py grâce à l'exception levée par le
module.
|
|
|
|
|
|
Utilisation d'une enum, pour que les valeurs possibles soient
explicites.
Renommage des points d'entrée pour qu'ils soient uniformes et
interchangeables.
Transformation du tag en liste plus bas pour que lilliput.py ne se
soucie pas des détails d'implémentation des fonctions en-dessous.
|
|
|
|
Et des fonctions d'initialisation. Et d'une fonction non-utilisée dans
le mode SCT-2.
|
|
|
|
Ce serait mieux si l'API renvoyait une exception… Un jour.
|
|
|
|
|
|
|
|
Aurais dû les enlever dans 23d2fea280302c01a818e46e4a43c884eac03865.
|
|
En passant :
- remplacement de paramètres 0/1 par des booléens/des enums (pour
TweakMessage en particulier, ça simplifie pas mal la logique)
- construction de M (resp. C pour le déchiffrement) au fur et à
mesure, i.e. avec des listes vides, plutôt qu'en pré-allouant des
tableaux potentiellement trop gros en cas de padding
|
|
Pour que le lien soit plus facile à faire avec la spec.
|
|
|
|
On peut tout déduire de len(tweak) / len(key) ; la seule raison
d'utiliser autant de constantes en C est que les tableaux se dégradent
en pointeurs, donc c'est où les constantes, où une tétrachiée
d'arguments.
|
|
|
|
Retrait de quelques variables globales par la même occasion. Renommage
de "round" en "i" pour 1) coller à la spec 2) éviter le conflit avec
le builtin "round".
|
|
|
|
|
|
tweak_bits est constant pour un mode donné ; rounds se déduit de la
taille de clé.
|
|
Création d'un nouveau module "helpers" qui contiendra les fonctions
utilisées par les deux modes.
|
|
Encore un peu de duplication sur les longueurs de clés valides. On y
travaille.
|
|
|
|
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…
🤷
|
|
|
|
|
|
Fournie par @aadomn.
|
