Chiffrement OpenSSL et PHP : faire les bons choix en 2026

Repère pratique

Distinguer mot de passe, clé, sel, IV et tag

Le mot de passe est une entrée humaine de faible entropie. Une fonction de dérivation comme PBKDF2 le transforme en clé à l’aide d’un sel et d’un nombre d’itérations. Le sel n’est pas secret ; il empêche notamment de réutiliser directement des calculs entre plusieurs fichiers. La clé obtenue doit rester secrète.

L’IV ou nonce évite que deux messages identiques produisent le même résultat avec une même clé. Ses contraintes dépendent du mode. Le tag d’authentification, dans un mode comme GCM, permet de détecter une modification. Confondre ces éléments ou réutiliser un nonce peut annuler les garanties attendues.

• Mot de passe : secret choisi ou stocké par un humain
• Sel : valeur publique et unique pour la dérivation
• Clé : secret cryptographique effectif
• IV ou nonce : valeur unique selon le mode
• Tag : preuve d’intégrité produite par un mode authentifié

Repère pratique

Ce que fait réellement openssl enc

La commande enc sait chiffrer avec plusieurs chiffrements symétriques et dériver une clé depuis un mot de passe. La documentation OpenSSL précise toutefois qu’elle ne prend pas en charge les modes AEAD comme GCM ou CCM. Elle ne fournit donc pas, à elle seule, le chiffrement authentifié recommandé pour beaucoup de nouvelles conceptions.

Pour un fichier manipulé manuellement, l’option -salt doit rester utilisée et -pbkdf2 améliore la dérivation par rapport aux anciens comportements. Le nombre d’itérations doit être choisi et documenté. N’inscris pas le mot de passe dans la ligne de commande : il peut apparaître dans l’historique ou la liste des processus. Utilise une source de secret adaptée à l’environnement.

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 200000 \
  -in document.txt -out document.enc

Repère pratique

Pourquoi PHP ne doit pas deviner le format

La fonction openssl_decrypt attend le nom du chiffrement, la clé, les options et l’IV. Elle ne reconstitue pas automatiquement toutes les conventions utilisées par la commande enc. Les anciennes sorties peuvent commencer par un en-tête contenant la marque Salted__ puis le sel, mais la méthode exacte de dérivation et ses paramètres doivent correspondre.

Évite de parser un format implicite dans une nouvelle application. Définis une enveloppe versionnée avec l’algorithme, l’identifiant de clé, le sel, le nonce, le tag et le texte chiffré. Encode les champs sans ambiguïté, valide leur taille et refuse toute version inconnue. Cette enveloppe permet de migrer sans tenter plusieurs algorithmes au hasard.

Repère pratique

Préférer le chiffrement authentifié

Le chiffrement sans authentification peut laisser une modification passer jusqu’à l’application. Pour une nouvelle conception, utilise une primitive AEAD telle qu’AES-GCM ou XChaCha20-Poly1305 via une bibliothèque de haut niveau. PHP fournit l’extension Sodium dans les versions modernes ; elle expose des constructions qui réduisent le nombre de paramètres dangereux.

Le choix ne se limite pas au nom de l’algorithme. Le nonce doit être généré conformément à l’API, le tag doit être vérifié avant d’utiliser le contenu et les erreurs ne doivent pas révéler des détails exploitables. Les données associées permettent aussi d’authentifier un contexte non chiffré, par exemple une version ou un identifiant.

Repère pratique

Gérer les clés comme des actifs

Une clé dans le dépôt Git, une image Docker ou un fichier accessible par le serveur web n’est pas réellement protégée. Utilise un gestionnaire de secrets, un KMS ou une séparation adaptée à la taille du système. Identifie les données protégées par chaque clé et prévois la rotation avant d’en avoir besoin.

La rotation exige un identifiant de clé dans le format. Les nouvelles écritures utilisent la clé courante ; les lectures reconnaissent l’ancienne jusqu’à migration. Journalise les opérations administratives sans enregistrer les secrets ni les données en clair. Teste aussi la perte du gestionnaire de clés : une sauvegarde chiffrée sans procédure de récupération peut devenir inutilisable.

Repère pratique

Checklist d’interopérabilité avant production

Écris des vecteurs de test fixes : entrée en clair non sensible, paramètres, sortie attendue et cas de corruption. Vérifie les deux directions entre la ligne de commande et PHP seulement si cette interopérabilité est réellement nécessaire. Teste les accents, les données binaires, les fichiers vides, les gros volumes et les erreurs de tag.

Documente la version du format, l’encodage, la dérivation, les tailles et les limites. Fais relire le protocole. Un test positif ne prouve pas la sécurité ; il prouve seulement que deux implémentations produisent le même résultat dans ce cas.

• Format versionné et non ambigu
• Algorithme et tailles documentés
• Nonce unique et tag vérifié
• Clés hors du code et identifiables
• Vecteurs de test et erreurs couvertes
• Plan de rotation et de récupération