| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
