| Age | Commit message (Collapse) | Author |
|
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>
|
|
|
|
Et suppression de l'implémentation add_tweakeysequences, qui n'a plus
aucun intérêt (plus lente et plus grosse que les deux autres).
|
|
|
|
|
|
|
|
|
|
On utilise des minuscules dans la spécification.
|
|
|
|
Pour qu'ils soient plus proches du nom donné dans la spécification.
|
|
Les renommages récents les ont chamboulées un peu.
|
|
Au final, il n'est pas moins performant que l'autre ; cf. issue #4.
|
|
- Changement de l'implémentation de référence en conséquence (les
compilateurs savent très bien optimiser les deux shifts en un seul
AND)
- Retouche du phrasé : "multiplication αᵢ" plutôt que "αᵢ
multiplication". Je n'ai pas de pointeurs vers une règle de
grammaire particulière, mais c'est par comparaison avec "Planet
Earth" ou "Operation Overlord".
|
|
|
|
|
|
Avec une phrase de documentation en prime pour chaque fichier.
Cf. issue #2.
|
|
Deux lignes vides avant le #endif, sauf pour parameters.h et
constants.h qui ne contiennent que des directives de préprocesseur.
|
|
|
|
Aucune idée de pourquoi j'avais insisté pour nommer les deux
"parameters" plutôt que de distinguer les constantes des paramètres.
Peut-être par souci de compatibilité avec FELICS, qui utilise
constants.h.
🤷
|
|
|
|
|
|
Ça me chiffonne de mettre deux instructions. En même temps, le cast me
chiffonne aussi, donc je reviendrai peut-être sur cette décision…
"x & 0x1f" a été remplacé par "(x<<3) >> 3" parce que c'est ce qu'un
lecteur qui déroulerait l'expression de M₃ trouverait, et aussi parce
que les compilateurs sont de toute façon suffisamment malins pour
traduire le tout en un AND.
|
|
|
|
|
|
|
|
|
|
Cette implémentation utilisera les matrices M², M³, MR² et MR³ telles
qu'exprimées dans la spécification, comme add_tabulatedtweakey ; en
revanche, les matrices 8×8 M₁, M₂, M₃ et M₄ seront codées par des
expressions booléennes (XORs et décalages) qui seront présentées dans
la section "implémentation" du papier.
|
|
Au passage, officialisation de la version "i applications successives
de M pour calculer Mⁱ" du key schedule.
|
|
Dans cette version, les multiplications par Mⁱ (resp. MRⁱ) sont faites
en appliquant M (resp. MR) i fois, plutôt qu'en utilisant les
expressions données dans la spécification.
|
|
Pour que la comparaison avec la spécification soit plus évidente.
|
|
|
|
En fait les séquences marchent dans un sens comme dans l'autre.
✨ MathéMagie ✨
|
|
|
|
Vu que la séquence générée par M₁ pour M² et M³ sera probablement
différente de la séquence générée pour MR³.
|
|
|
|
Les résultats changent, mais sont maintenant conformes à ceux de Léo.
|
|
*Toutes* les opérations s'appliquent dans l'autre sens, *y compris les
shifts*, vu que on prend (y₀…y7)ᵗ = MR(x₀…x₇)ᵗ.
|
|
Plus facile pour suivre la spec.
|