| Age | Commit message (Collapse) | Author |
|---|
|
Et ajout d'un métascript pour vérifier la conformité.
Il ne reste plus qu'à… (bis)
|
|
|
|
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.
|
|
Un peu de machinerie à mettre en place pour permettre l'ajout de
fichiers arbitraires dans une implémentation.
|
|
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>
|
|
Pour qu'ils soient plus proches du nom donné dans la spécification.
|
|
|
|
|
|
|
|
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.
🤷
|
|
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.
|
|
|
|
(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.
|
|
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³.
|
|
|
|
|
|
*Toutes* les opérations s'appliquent dans l'autre sens, *y compris les
shifts*, vu que on prend (y₀…y7)ᵗ = MR(x₀…x₇)ᵗ.
|
|
|
|
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.
|
|
|
|
Ajout d'une fonction pour récupérer facilement la nouvelle valeur des
vecteurs.
|
|
|
|
|
|
|
|
|
|
|
