| Age | Commit message (Collapse) | Author |
|---|
|
Il ne devrait pas varier selon les paramètres AFAICT.
|
|
|
|
Avec debug.h, il devrait être facile d'ajouter des traces en cas de
besoin.
|
|
Régénérés par Léo avec 528 bits = 66 octets.
|
|
Tests toujours en vrac, vu que Léo rembourre des bits et moi des
octets.
|
|
Le test ne passe pas pour le moment ; les résultats de Léo ont été
calculés avec |M| = 521 bits ; l'implémentation en C ne gère que des
tailles en octet pour le moment.
|
|
Et les tests passent. Merci Léo !
|
|
"Tiens c'est marrant mon octet vaut zéro un coup sur deux."
(Test toujours KO pour le moment)
|
|
Différent de la version C, pour le moment.
|
|
Avec une suite de test qui passe.
|
|
|
|
Et 2-3 corrections au passage :
- taille du tweak dans les commentaires
- remplissage du tweak pour les données associées
- ordre des arguments
|
|
Reste le tweak.
Au passage, 2-3 nettoyages (const-correctness, renommages de variables
et suppressions de constantes pour essayer d'être plus proche de la
spec visuellement).
|
|
|
|
|
|
|
|
|
|
Herp derp.
|
|
Et des vecteurs de test.
|
|
Herp derp.
|
|
Et des vecteurs associés… même si c'est tautologique pour le
moment (i.e. les nouvelles sorties "attendues" ont été générées avec
ce code de ref ; pas encore de confirmation de Léo pour le moment).
|
|
|
|
|
|
La comparaison avec les sorties attendues est faite directement dans
le code ; libre au développeur d'aller differ les répertoires en cas
de problème.
|
|
crypto_aead.h est fourni ici :
https://csrc.nist.gov/CSRC/media/Projects/Lightweight-Cryptography/documents/TestVectorGen.zip
|
|
Pas vraiment de raison, si ce n'est que ça simplifie la construction
de l'api.h attendu par le NIST.
Aussi, ajout de la taille du nonce.
|
|
La flemme de réfléchir aux problèmes de portabilité.
|
|
J'étais parti du principe que pour inverser
non-linear layer
r0 linear layer
permutation layer
…
non-linear layer
r31 linear layer
/
Il allait falloir faire
non-linear layer
r0 linear layer
/
…
non-linear layer
r31 linear layer
permutation layer
Mais en fait non, on procède comme au chiffrement : c'est le dernier
tour qui saute la permutation. C'est bien précisé dans
Lilliput (annexe B, figure 8).
✨ MathéMagie ✨
|
|
|
|
tbc-decrypt inbound.
|
|
Toujours conforme au vecteur de test ! Le test passe, du coup.
J'ai un doute sur la gestion des indices de π, ceci dit.
|
|
Toujours conforme au vecteur de test.
|
|
So far so good.
|
|
Plus qu'à implémenter maintenant.
|
|
J'aimerais éviter de trimballer des variables dans toutes mes
fonctions juste pour débugger.
|
|
Implémentation de test-cipher.c en passant.
|
|
Ce nom sera utilisé pour une fonction plus simple qui ne wrappera pas
à 8 octets.
|
|
|
|
Pour que cipher.c puisse s'en servir.
|
|
La gestion de la permutation est probablement pas élégante… 🤷
|
|
I.e. définition des fonctions de haut-niveau ; reste à implémenter les
fonctions en-dessous, et les sorties de debug.
|
|
Notamment de la partie debug du tweakey, pour permettre de ne pas
polluer la sortie des autres tests.
|
|
|
|
Permet d'isoler les paramètres propres à la taille de clé et au mode ;
normalement, le reste du code devrait être strictement identique d'un
dossier à l'autre.
|
|
Permettra d'ajouter un nouveau test plus facilement.
|
|
|
|
|
|
J'avais oublié
- de virer le 33ème tour de null et full,
- de mettre à jour les valeurs de random dans le code C
TODO: lire ces valeurs automatiquement depuis le fichier de référence…
|
|
Aucune idée de si null et full devraient aussi être mis à jour. Pour
null j'ai l'impression que non ; pour full j'ai l'impression que si.
🤷
|
|
… Et bien sûr, les résultats divergent. E.g. pour le vecteur random :
Post permutation Tweakey :
- b4 16 73 a9 ae 56 44 ca
- f3 d1 19 a2 f1 00 13 28
- 25 0e 90 39 33 c5 28 33
- d2 ff 52 a5 12 73 5b 19
- 26 04 0b cf 2d 5e d4 4c
+ b4 73 ae 44 16 ca a9 56
+ f3 19 f1 13 d1 28 a2 00
+ 25 90 33 28 0e 33 39 c5
+ d2 52 12 5b ff 19 a5 73
+ 26 0b 2d d4 04 4c cf 5e
|
