| Age | Commit message (Collapse) | Author |
|
|
|
|
|
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.
|
|
Pour correspondre à genkat_aead.c.
|
|
|
|
|
|
Et ré-adaptation de l'API de lilliput.py pour simplifier
l'interfaçage ; et retrait des print() pour accélérer la génération
des vecteurs (qui même comme ça prend 2 bonnes minutes).
NB : pour le moment, les vecteurs ne correspondent pas…
|
|
Pour qu'on puisse plus facilement manipuler les entrées/sorties.
Pour le moment le round-trip chiffrement/déchiffrement marche.
import lilliput
message = 'Hello 🌐!'
adata = 'Signed: Kévin'
for mode in 1,2:
for keylen in 128, 192, 256:
ct, tag = lilliput.mainEnc(message, adata, mode, keylen)
pt = lilliput.mainDec(ct, tag, adata, mode, keylen)
assert message == pt
|
|
|
|
Ça m'embêtait qu'on liste plusieurs personnes, puis qu'on dise "the
implementer has…" ; repompé le "hereby denoted…" de Keccak.
|
|
Un peu de machinerie à mettre en place pour permettre l'ajout de
fichiers arbitraires dans une implémentation.
|
|
- retrait de stdio.h (inutile)
- "aération" du prototype de _state_init
|
|
- fins de ligne UNIX (\n)
- espaces plutôt que tabulations
|
|
Dans le but de rendre
diff -ru ref add_threshold
plus digeste.
|
|
- ordre alphabétique des auteurs,
- un auteur par ligne, date sur une ligne séparée : maintenance et
diff plus simples,
- brève description de chaque fichier.
|
|
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>
|
|
|
|
Et suppression de l'implémentation add_tweakeysequences, qui n'a plus
aucun intérêt (plus lente et plus grosse que les deux autres).
|
|
|
|
|
|
|
|
|
|
On utilise des minuscules dans la spécification.
|
|
|
|
Pour qu'ils soient plus proches du nom donné dans la spécification.
|
|
|
|
|
|
Reformulations des considérations d'implémentation sur le tweakey schedule
See merge request paclido/sp3!11
|
|
|
|
Les renommages récents les ont chamboulées un peu.
|
|
Au final, il n'est pas moins performant que l'autre ; cf. issue #4.
|
|
- 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.
|
|
|
|
|