| Age | Commit message (Collapse) | Author |
|
- 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.
|
|
|
|
|
|
Comme mentionné dans le commit précédent, ce test devrait permettre de
détecter des déviations par rapport à l'implémentation de référence.
Les tests de Lilliput-Ⅰ-128 remplissent le même rôle, mais je n'avais
pas envie de passer du temps à les copier-coller puis à les adapter
aux différentes tailles de clés et de tweaks.
|
|
Bricolé pendant la réunion SP3 du 1er février, inachevé.
Je me suis rendu compte que les "tests", en dehors des tests de
Lilliput-Ⅰ-128, se contentent de vérifier que D(E(plaintext)) =
plaintext, ce qui ne suffit pas pour s'assurer qu'une nouvelle
implémentation est conforme à l'ancienne.
Plutôt que de copier-coller-adapter les tests de Lilliput-Ⅰ-128, il me
semble qu'une approche plus simple serait de comparer les vecteurs
générés par une implémentation à ceux produits par l'implémentation de
référence.
|
|
|
|
|
|
|
|
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.
|
|
🤞
|
|
|
|
Herp derp.
|
|
|
|
(Plus précisément, la variante Airbus qui gère les AEAD)
|
|
|
|
|
|
|
|
Au passage, officialisation de la version "i applications successives
de M pour calculer Mⁱ" du key schedule.
|
|
Les constantes ont été ventilées dans les modules qui s'en
servent (tweakey.c, cipher.c).
|
|
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³.
|
|
|
|
This reverts commit 7a0789a3abb151e80959f4f802c9154e5c2899c3.
Paul confirme qu'il faut apporter une correction à M³ ; avec un peu de
chance, on peut donc garder les tests tels qu'il étaient avant de
déplier M³.
|
|
|
|
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.
|
|
Les tests passent, c'est encourageant.
|
|
|
|
|
|
Pour le moment, Mⁱ (resp. MRⁱ) sont implémentées en appliquant i fois
M (resp. MR) ; à voir si on préfère les pré-calculer.
|
|
|