Quel est le moyen le plus sûr pour une partie de crypter 4 octets en moins de 40 octets, qui seront accessibles au public?
J'ai un projet où un utilisateur a besoin de stocker un U32 chiffré sur une blockchain afin de pouvoir le récupérer lui-même: l'utilisateur aura toujours sa clé disponible mais pourra "oublier" la valeur U32. Aucune autre partie n'a besoin de décoder les informations, mais le texte en clair sera finalement également public sur la chaîne.
L'utilisateur a une graine d'entropie à partir de laquelle un nombre infini de clés de n'importe quelle taille peut être dérivé de manière déterministe. Je cherchais à utiliser un seul bloc d'AES mais il m'est venu à l'esprit qu'un simple XOR suffirait également. En supposant que l'utilisateur tire une «clé» unique chaque fois qu'il effectue ce type d'opération, y a-t-il une raison de faire quelque chose de plus compliqué que cela?
Réponses
La réponse évidente est d'utiliser un tampon unique . Si vous utilisez vraiment une clé aléatoire unique de 4 octets pour chaque bloc de 4 octets, il est prouvé qu'elle est sécurisée.
L'utilisateur a une graine d'entropie à partir de laquelle un nombre infini de clés de n'importe quelle taille peut être dérivé de manière déterministe.
Le vrai problème est ce caractère aléatoire «dérivé» et à quel point il est réellement aléatoire. Je n'en connais aucune source infinie.
Avec Salsa / ChaCha, vous pouvez générer jusqu'à 2 ^ 64 clés de 512 bits, chaque clé étant capable de crypter 16 blocs de 4 octets différents. Donc je suppose que c'est assez infini.
Les utilisateurs auraient besoin de le semer avec une clé de 320 bits. Ils doivent changer leur clé après 2 ^ 68 (si mes calculs ne sont pas erronés). L'utilisation d'une configuration similaire à XChaCha vous permet d'étendre cela à 2 ^ 132.
En résumé, si vous disposez d'une source aléatoire sécurisée par cryptographie, vous pouvez simplement XOR.
Ainsi, la solution standard d'un cryptographe avec ces contraintes serait d'utiliser AES-128-GCM avec un nonce de 12 octets et une étiquette d'authentification de 16 octets en utilisant une clé secrète fixe.
Cependant, le fait que cette valeur soit stockée sur la blockchain permet certaines réductions de taille unqiue :
- Le nonce peut être supprimé et à la place re-dérivé du nombre de valeurs écrites dans la blockchain - qui est récupérable en inspectant l'état passé de la chaîne. Cela suppose que la clé est uniquement utilisée pour cette application et non autre utilisation de la clé peut accidentellement utiliser la même paire de clés / nonce que toute transaction.
- La balise d'authentification peut être supprimée car vous savez toujours ce qu'est le texte chiffré et elle ne peut pas être modifiée après soumission grâce à la signature sur la transaction et à la nature immuable d'une blockchain. Notez que cela suppose que lors de la récupération de la valeur, vous faites confiance au client blockchain pour ne pas fournir une valeur erronée ou que vous pouvez également récupérer la transaction signée pertinente et la vérifier.
Maintenant, si vous supprimez les deux, vous vous retrouvez essentiellement avec AES-128-CTR qui calcule $\operatorname{AES}_K(C)\oplus M$ pour une clé fixe $K$ et votre contre-valeur $C$ et un message $M$. Notez que cela n'entraîne aucune extension de message car vous pouvez simplement redériver la même partie de la sortie AES pour le déchiffrement.