Points clés
- L’AEAD chiffre et authentifie au cours d’une même opération.
- Les données associées restent lisibles mais sont protégées contre la modification.
- Un nonce ne doit jamais être réutilisé avec la même clé.
- Le texte en clair ne doit être exploité qu’après validation du tag.
Définition et périmètre
ChaCha20 produit un flux de clés pour le chiffrement, tandis que Poly1305 calcule un tag d’authentification sur les données associées et le texte chiffré. Au déchiffrement, l’implémentation doit vérifier ce tag avant de remettre le texte en clair au reste de l’application. [1]
Frontière de sécurité
Les données associées conviennent à une version de format, un identifiant d’enregistrement ou un contexte de protocole qui ne doivent pas rester secrets. Leur présence dans le tag les lie cryptographiquement au texte chiffré et révèle une modification, sans les chiffrer. [1]
Limites et évaluation
Réutiliser un nonce avec la même clé peut révéler des relations entre textes en clair et compromettre l’authentification. L’AEAD ne protège par ailleurs ni un terminal compromis, ni la longueur du message, ni les métadonnées volontairement laissées hors du périmètre chiffré. [1]
Questions fréquentes.
Que signifie AEAD et ChaCha20-Poly1305 ?
AEAD protège la confidentialité et l’intégrité du texte chiffré et des données associées non chiffrées. ChaCha20-Poly1305 est une construction AEAD standardisée par la RFC 8439. [1]
Que ne garantit pas AEAD et ChaCha20-Poly1305 ?
Réutiliser un nonce avec la même clé peut révéler des relations entre textes en clair et compromettre l’authentification. L’AEAD ne protège par ailleurs ni un terminal compromis, ni la longueur du message, ni les métadonnées volontairement laissées hors du périmètre chiffré. [1]
Comment SealTask situe-t-il AEAD et ChaCha20-Poly1305 ?
SealTask emploie ChaCha20-Poly1305 pour les champs de contenu protégés et leur associe des informations de schéma et de contexte. La génération des nonces et la séparation des clés font partie du protocole client documenté. [2]
Sources primaires
Les définitions privilégient les organismes de normalisation, les autorités publiques et l’architecture SealTask de première partie. Les liens ouvrent la source complète.
- 01 RFC 8439: ChaCha20 and Poly1305 for IETF Protocols Source primaire ou de première partie pour la définition, les exigences du protocole, la frontière de sécurité ou le contexte réglementaire.
- 02 SealTask security architecture Source primaire ou de première partie pour la définition, les exigences du protocole, la frontière de sécurité ou le contexte réglementaire.