#dusk $DUSK @Dusk
Ce qui m’intéresse dans le design de la confidentialité de Dusk, ce n’est pas seulement que les notes sont cachées. C’est l’endroit où se produit le masquage, et le nombre d’hypothèses qui doivent toutes être vraies en même temps.
Phoenix utilise des engagements et un arbre de Merkle, tandis que les engagements de valeur ajoutent un facteur d’aveuglement. Les validateurs peuvent vérifier la cohérence sans apprendre le montant. Les adresses furtives rendent aussi plus difficile le rapprochement des destinataires.
La couche de chiffrement, c’est là que je regarde encore plus attentivement. Phoenix expose actuellement AES comme chiffrement symétrique, tandis que la pile inclut aussi JubJub ElGamal et Poseidon. La bibliothèque Poseidon de Dusk dispose de fonctionnalités de chiffrement, mais dire « Poseidon fournit la confidentialité » est trop simpliste. L’implémentation a évolué, et cela compte lorsqu’on juge la sécurité sémantique.
Ma vraie question est de savoir si la composition a été prouvée comme un seul système. Un engagement peut masquer une valeur et le chiffrement peut masquer du texte en clair, mais la confidentialité peut tout de même échouer à cause des métadonnées, de la gestion des clés, d’une mauvaise utilisation des nonces, de la corrélation d’adresses, ou d’une relation de preuve défectueuse. J’ai déjà vu cela : des primitives solides ne rendent pas automatiquement un protocole solide.
Poseidon est conçu pour des calculs compatibles avec la ZK, tandis que AES est mature pour le chiffrement général. Cela peut aider les performances, mais cela rend importante la frontière entre chiffrer, engager et prouver.
Je ne suis pas prêt à faire confiance à la construction parce que les ingrédients sont respectés. Je veux un argument formel montrant que le chiffrement des notes masque les valeurs et les identités. C’est là que l’affirmation de confidentialité de Dusk devient quelque chose que je peux évaluer.
Ce qui m’intéresse dans le design de la confidentialité de Dusk, ce n’est pas seulement que les notes sont cachées. C’est l’endroit où se produit le masquage, et le nombre d’hypothèses qui doivent toutes être vraies en même temps.
Phoenix utilise des engagements et un arbre de Merkle, tandis que les engagements de valeur ajoutent un facteur d’aveuglement. Les validateurs peuvent vérifier la cohérence sans apprendre le montant. Les adresses furtives rendent aussi plus difficile le rapprochement des destinataires.
La couche de chiffrement, c’est là que je regarde encore plus attentivement. Phoenix expose actuellement AES comme chiffrement symétrique, tandis que la pile inclut aussi JubJub ElGamal et Poseidon. La bibliothèque Poseidon de Dusk dispose de fonctionnalités de chiffrement, mais dire « Poseidon fournit la confidentialité » est trop simpliste. L’implémentation a évolué, et cela compte lorsqu’on juge la sécurité sémantique.
Ma vraie question est de savoir si la composition a été prouvée comme un seul système. Un engagement peut masquer une valeur et le chiffrement peut masquer du texte en clair, mais la confidentialité peut tout de même échouer à cause des métadonnées, de la gestion des clés, d’une mauvaise utilisation des nonces, de la corrélation d’adresses, ou d’une relation de preuve défectueuse. J’ai déjà vu cela : des primitives solides ne rendent pas automatiquement un protocole solide.
Poseidon est conçu pour des calculs compatibles avec la ZK, tandis que AES est mature pour le chiffrement général. Cela peut aider les performances, mais cela rend importante la frontière entre chiffrer, engager et prouver.
Je ne suis pas prêt à faire confiance à la construction parce que les ingrédients sont respectés. Je veux un argument formel montrant que le chiffrement des notes masque les valeurs et les identités. C’est là que l’affirmation de confidentialité de Dusk devient quelque chose que je peux évaluer.