| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- mise à jour des vecteurs de test i-128/test-ae-*crypt
- affichage des tableaux d'octets par indices croissants
|
|
|
|
|
|
L'idée étant que tous les scripts qui génèrent des dossiers au format
crypto_aead consultent ce fichier au lieu de coder la version en dur.
Un tag git pourrait probablement être utilisé au lieu d'un fichier.
À réfléchir.
|
|
|
|
|
|
Et petits nettoyages par-ci par-là.
|
|
|
|
Pour que ce soit plus simple de remplacer la boucle par
generate 2 128
generate 1 256
… ce qui prend 6 minutes au lieu de 20 sur ma machine \o/
|
|
De sorte à ce qu'on puisse le lancer depuis n'importe quel dossier.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
