Le titre d'ingénieur cryptographie recouvre des postes différents. Chez un éditeur de produits de sécurité ou un fabricant de composants, la personne implémente des primitives et des protocoles en C ou en Rust, souvent sur des cibles embarquées, et prépare les évaluations CSPN ou Critères communs. Dans une grande équipe sécurité, elle conseille les développeurs, relit les conceptions et choisit les bibliothèques. Les offres publiées sur Free-Work citent aussi la programmation en temps constant, les attaques par canaux auxiliaires et la migration post-quantique.
Le diplôme ne suffit pas à trier. Un docteur en cryptologie peut n'avoir jamais livré de code en production, et un ingénieur autodidacte peut avoir corrigé des failles réelles dans une bibliothèque connue. L'entretien porte sur ce que la personne a écrit, relu ou cassé, avec le nom du projet et la nature du défaut.
Un expert technique siège dans le jury : les réponses justes et les réponses approximatives se ressemblent pour un non-spécialiste. Le PDF propose 30 questions sur six axes, un cas de 20 minutes sur la mise à jour d'objets connectés et une grille de 1 à 4.
Primitives, protocoles et outils d'un ingénieur cryptographie
Chiffrement symétrique et AEAD
AES-GCM, ChaCha20-Poly1305 et AES-GCM-SIV chiffrent et authentifient en une opération. Leur point faible est l'usage : un nonce réutilisé avec la même clé en GCM détruit la confidentialité et permet de forger des messages. Un bon candidat en parle avant même la longueur de clé.
Asymétrique et dérivation
RSA, ECDSA, Ed25519 et X25519 pour la signature et l'échange de clés, HKDF pour dériver des clés à partir d'un secret partagé, Argon2id ou scrypt pour les mots de passe. Le choix dépend de la compatibilité, de la performance et des exigences de certification.
Post-quantique : ML-KEM, ML-DSA, SLH-DSA
Les trois normes FIPS 203, 204 et 205 publiées par le NIST en août 2024. L'ANSSI recommande de les déployer en mode hybride, combinées à un algorithme classique. Le NIST a publié en octobre 2026 la version finale de son rapport IR 8547 sur la transition.
Protocoles : TLS 1.3, IKEv2, Signal
TLS 1.3 pour le transport, IKEv2 pour IPsec, le Double Ratchet et PQXDH de Signal pour la messagerie, le cadre Noise pour des protocoles plus légers. Le poste demande de savoir pourquoi ils sont construits de cette façon, et où se cachent les rétrogradations et les rejeux.
Bibliothèques : OpenSSL, BoringSSL, AWS-LC, libsodium
OpenSSL 3.5, version LTS supportée jusqu'au 8 avril 2030, intègre ML-KEM, ML-DSA et SLH-DSA et propose par défaut l'échange hybride X25519MLKEM768 en TLS. OpenSSL 3.0 n'est plus supporté. libsodium offre une API plus difficile à mal employer, BoringSSL et AWS-LC sont les branches de Google et d'AWS.
C et Rust
Les deux langages de l'implémentation. Le C domine l'embarqué et les bibliothèques historiques. Rust apporte la sûreté mémoire, avec les crates RustCrypto, ring ou aws-lc-rs, mais ne garantit pas le temps constant : le compilateur peut réintroduire une branche dépendant d'un secret.
Outils de vérification
Les vecteurs de test du projet Wycheproof et du NIST, le fuzzing différentiel contre une implémentation de référence, dudect ou Valgrind pour détecter des fuites de temps, ProVerif et Tamarin pour la preuve symbolique de protocoles. Un candidat expérimenté en cite au moins deux qu'il a lancés.
Référentiels ANSSI et NIST
Le guide de sélection d'algorithmes cryptographiques de l'ANSSI, ses recommandations pour TLS et IPsec, la certification CSPN, les publications NIST SP 800-57 et SP 800-38D, et FIPS 140-3 pour les modules validés. Ils fixent les choix admis lors d'une évaluation.
Le poste existe chez les éditeurs de produits de sécurité, les fabricants de cartes, de composants et d'objets connectés, les éditeurs de messagerie chiffrée ou de VPN, les laboratoires d'évaluation et dans les équipes sécurité des grands groupes. Les profils se répartissent entre implémentation (bibliothèques, firmware, accélération), conception et revue (protocoles, architecture) et recherche (cryptanalyse, nouveaux schémas). La migration post-quantique a ouvert des postes dédiés, avec une variante de poste à part. Pour un produit évalué en CSPN ou en Critères communs, l'ingénieur prépare la documentation des mécanismes et répond aux questions de l'évaluateur. La demande reste faible en volume et les profils confirmés sont rares, ce qui allonge les recrutements.
Six compétences à vérifier chez un cryptographe
- Primitives et choix d'algorithmes
- Implémentation sûre et canaux auxiliaires
- Protocoles et leurs failles
- Bibliothèques, tests et code C ou Rust
- Cryptanalyse appliquée et revue de conception
- Référentiels, évaluation et transition
Questions d'entretien pour un ingénieur cryptographie
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Un service chiffre ses messages en AES-GCM avec un nonce aléatoire de 96 bits et une seule clé pour des milliards de messages. Qu'en pensez-vous ?
Une bonne réponseLe risque est la collision de nonces : avec des nonces aléatoires de 96 bits, le NIST (SP 800-38D) limite le nombre de chiffrements par clé à 2 puissance 32. Une collision réutilise le flux de clé et expose la clé d'authentification, ce qui permet de forger des messages. Les réponses : un compteur comme nonce, une rotation de clé avant la limite, une dérivation de clé par message, ou un mode qui tolère mieux l'erreur (AES-GCM-SIV, XChaCha20-Poly1305 avec son nonce de 192 bits).
Signal d'alerte« GCM est authentifié, donc c'est sûr », sans aucune notion de limite par clé ni de conséquence d'un nonce répété.
Question 2 · senior
Comment vérifiez-vous qu'une comparaison de MAC ou une opération sur une clé secrète s'exécute en temps constant ?
Une bonne réponsePas de branche ni d'accès mémoire qui dépende d'un secret, une comparaison dédiée (CRYPTO_memcmp, sodium_memcmp, crate subtle en Rust). Puis une vérification : test statistique avec dudect, Valgrind avec le secret marqué comme non initialisé pour détecter les branches, lecture de l'assembleur produit, car le compilateur peut réintroduire une branche. Elle cite une faille réelle, comme KyberSlash, où une division sur une donnée secrète fuyait le temps.
Signal d'alertememcmp, ou « j'ajoute un délai aléatoire pour brouiller la mesure ».
Question 3 · confirmé
En TLS 1.3, qu'apporte la confidentialité persistante, et quel risque portent les données envoyées en 0-RTT ?
Une bonne réponseTLS 1.3 a retiré l'échange de clés RSA statique : chaque session utilise un échange (EC)DHE éphémère, donc le vol ultérieur de la clé du serveur ne déchiffre pas les sessions passées. Les données 0-RTT, chiffrées avec une clé issue d'une session précédente, peuvent être rejouées par un attaquant. On ne les accepte que pour des requêtes idempotentes, avec une protection contre le rejeu côté serveur. Elle note aussi qu'une reprise de session par PSK sans échange DHE perd la confidentialité persistante.
Signal d'alerteUne confusion entre 0-RTT et reprise de session, ou l'idée que TLS 1.3 empêche tout rejeu.
Question 4 · confirmé
Vous devez choisir une bibliothèque cryptographique pour un nouveau service. Sur quels critères tranchez-vous ?
Une bonne réponseLa maintenance et le cycle de vie (OpenSSL 3.0 n'est plus supporté, la 3.5 LTS l'est jusqu'en avril 2030), l'historique des audits et des CVE, une API difficile à mal employer (libsodium, ring), le besoin d'un module validé FIPS 140-3 (fournisseur FIPS d'OpenSSL, AWS-LC), la couverture des algorithmes dont le post-quantique, la taille et la portabilité pour l'embarqué. Jamais de primitive écrite maison quand une implémentation reconnue existe.
Signal d'alerte« J'écris mon propre AES, c'est plus rapide et je maîtrise le code. »
Question 5 · senior
On vous confie la revue d'un protocole maison d'authentification entre des objets connectés et un serveur. Par où commencez-vous ?
Une bonne réponsePar le modèle de menace et les propriétés attendues : qui authentifie qui, ce que l'attaquant contrôle, ce qui se passe si une clé d'objet fuit. Puis le déroulé des messages : protection contre le rejeu (nonces, compteurs), liaison des identités au transcript, dérivation de clés avec HKDF, rétrogradation possible, confidentialité persistante. Elle propose de remplacer le protocole par un standard (TLS 1.3, EDHOC, un motif Noise) si rien ne justifie le maison, et de modéliser avec ProVerif ou Tamarin.
Signal d'alerteLister les algorithmes utilisés et conclure « AES-256 et SHA-256, c'est sûr ».
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Cryptographe : questions fréquentes
Quelle différence avec un ingénieur HSM ou un ingénieur PKI ?
L'ingénieur HSM et l'ingénieur PKI exploitent des produits : modules matériels, autorités de certification, KMS. Ils choisissent des paramètres et tiennent des procédures. L'ingénieur cryptographie travaille un cran en dessous, sur les primitives, les protocoles et leur implémentation, et sait expliquer pourquoi une construction est sûre ou ne l'est pas. Un poste qui consiste surtout à administrer des HSM et des certificats relève de la première famille, même si l'offre parle de cryptographie.
Un doctorat est-il nécessaire pour un poste de cryptographe ?
Pour un poste de recherche, en cryptanalyse ou sur de nouveaux schémas, le doctorat est souvent attendu. Pour un poste d'implémentation ou de revue, un ingénieur avec de bonnes bases mathématiques et une vraie pratique du C ou du Rust convient. Comptent les contributions publiques, les corrections de failles, les articles ou les évaluations menées. Le titre seul ne dit pas si la personne a déjà livré du code cryptographique utilisé en production.
Quel test technique proposer à un ingénieur cryptographie ?
Un extrait de code de 50 à 100 lignes à relire, en C ou en Rust, avec quelques erreurs classiques : nonce fixe, comparaison de MAC non constante, clé dérivée d'un mot de passe par un simple hachage, absence de vérification du tag. La personne commente à voix haute pendant 20 minutes et propose les corrections. Pour un poste orienté conception s'ajoute un schéma de protocole à critiquer.
Comment repérer un candidat qui récite sans avoir pratiqué ?
Il cite des algorithmes et des longueurs de clé, rarement des erreurs d'usage. Le récit de la dernière faille qu'il a trouvée ou corrigée, avec l'outil qui l'a révélée et le correctif livré, en dit beaucoup. Ce qu'il ferait différemment dans un projet passé est tout aussi parlant. Un praticien parle de nonces, de vecteurs de test, de fuites de temps et de compromis avec la performance, et reconnaît volontiers ce qu'il ne sait pas.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
