C'est hardcodé ? Parce que si c'est le cas, un logiciel de chiffrement qui utilise un algorithme, sans possibilité d'évolution, c'est à mettre d'office à la poubelle, pour éviter de devoir le faire lorsque ce sera devenu un problème de sécurité.
L’idée de laisser l’utilisateur/le développeur choisir l’algorithme et ses paramètres est aujourd’hui considéré comme une fausse bonne idée en cyptographie. C’est au cryptographe de faire ces choix et de fournir à l’utilisateur/développeur final une interface suffisament simple pour être impossible à mésutiliser (si tu demandes au développeur de gérer le nonce lui même, tu peux être sûr que tu auras des développeurs qui réutiliseront le même nonce pour la même clé ; si tu demandes au développeur de choisir l’algo tu te retrouveras un moment avec des choses comme https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/).
C’est ce que font tous les designs cryptographiques modernes : libsodium/libhydrogen (côté libs) matrix/signal (côté programmes). TLS 1.3 a aussi fait un gros travail de nettoyage dans les possibilités offertes.
Et oui, ça signifie que si demain XChaCha20 est cassé il faudra un age 2.0 et un libsodium 2.0.
Ceci dit la partie de KEM est effectivement configurable si c’est pour des cas d’usage différents : X25519 pour clé publique, ou scrypt pour protection par mot de passe (donc symmétrique). Et vu age que peut utiliser les clés SSH, tu as aussi la possibilité d’utiliser RSA : https://github.com/FiloSottile/age/blob/main/agessh/agessh.go#L170
[^] # Re: X25519
Posté par Moonz . En réponse à la dépêche Sortie de la version 1.0.0 de age. Évalué à 2. Dernière modification le 02 novembre 2021 à 10:37.
L’idée de laisser l’utilisateur/le développeur choisir l’algorithme et ses paramètres est aujourd’hui considéré comme une fausse bonne idée en cyptographie. C’est au cryptographe de faire ces choix et de fournir à l’utilisateur/développeur final une interface suffisament simple pour être impossible à mésutiliser (si tu demandes au développeur de gérer le nonce lui même, tu peux être sûr que tu auras des développeurs qui réutiliseront le même nonce pour la même clé ; si tu demandes au développeur de choisir l’algo tu te retrouveras un moment avec des choses comme https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/).
C’est ce que font tous les designs cryptographiques modernes : libsodium/libhydrogen (côté libs) matrix/signal (côté programmes). TLS 1.3 a aussi fait un gros travail de nettoyage dans les possibilités offertes.
Et oui, ça signifie que si demain XChaCha20 est cassé il faudra un age 2.0 et un libsodium 2.0.
Ceci dit la partie de KEM est effectivement configurable si c’est pour des cas d’usage différents : X25519 pour clé publique, ou scrypt pour protection par mot de passe (donc symmétrique). Et vu age que peut utiliser les clés SSH, tu as aussi la possibilité d’utiliser RSA : https://github.com/FiloSottile/age/blob/main/agessh/agessh.go#L170