La version 1.0.0 de Age est sortie le 6 septembre 2021 après environ 2 ans de développement.
Age est à la fois un format de fichier (age-encryption.org/v1), dont la spécification (lien vers Google Documents) se veut très simple, et un outil en ligne commande sous licence BSD 3 clauses, dont le but est de chiffrer des fichiers.
Description
Age a été crée par Filippo Valsorda (qui travaille sur la cryptographie et la sécurité dans Go) dans le but de proposer une alternative à OpenPGP/GPG pour échanger des fichiers chiffrés.
Les griefs contre OpenPGP et GPG sont légions et Filippo souhaitait définir un format de fichier et créer une interface utilisateur qui soit beaucoup plus simple à comprendre et à utiliser (de la même manière que les développeurs de WireGuard souhaitaient ne pas reproduire ce qui se fait avec IPSec).
D’un point de vu cryptographique, Age utilise des clefs X25519 et peut soit générer des clefs qui lui sont spécifiques (via age-keygen), soit utiliser des clefs SSH.
Exemple d’utilisation :
$ age-keygen
# created: 2021-05-11T14:30:10-04:00
# public key: age1p7n6yyke4q02m2uzy2f5v9w0znelxm72gktm038k5t0t7z72cs5qsnhvaw
AGE-SECRET-KEY-1FXDQJDV9YX0DPYV2PGDT3W2HLG6LNAK8NA53PRS6GMRWHVQHCEWSTS9VJ
$ echo 'Hello world!' | age -a -r age1p7n6yyke4q02m2uzy2f5v9w0znelxm72gktm038k5t0t7z72cs5qsnhvaw
-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBrSXZadVlhdko5aGVjU25w
K3BlTlF5YUVMclN6L2NvUjBjeGYrWTM1NXl3ClA0eHB3T2NwZ3dMNTJPS0tVUHhJ
bGUyV2NGSndPdEM4Rlh1MkFBYU1VdzAKLS0tIEk4WG91SE13LzhvSEQxdlFwLzh0
ZnFGdFYvVGQxcHd1K0NVZGFZOEJhemsK5IVbACUVOEO+8UnCtG6UedxKAlnGbBfI
6J91FdVTORX7RmsczeD3Uouqq4xi
-----END AGE ENCRYPTED FILE-----
Disponibilité
Age est écrit en Go et des binaires pré-compilés sont disponibles avec chaque nouvelle version sur GitHub. Il est également disponible pour les distributions Linux majeures (Debian, Ubuntu, ArchLinux, Fedora, Nix) ainsi que Windows, MacOS, OpenBSD et FreeBSD.
Voir la documentation sur l’installation pour plus de détails.
Autres implémentations
rage
Rage est une implémentation en Rust, sous licences Apache 2.0 et MIT, qui propose des fonctionnalités en plus par rapport à l’implémentation de référence, comme, par exemple, la possibilité de monter une archive TAR chiffrée.
SOPS
L’outil de gestion de secrets SOPS de Mozilla gère le chiffrement via age depuis la version 3.7.0. Il utilise l’implémentation de référence sous forme de bibliothèque.
Critique
Neil Madden a émis plusieurs critiques sur son blog, notamment concernant des défaillances dans le chiffrement authentifié et le syndrome NIH de l’auteur.
Filippo Valsorda y a répondu sur la liste de diffusion du projet.
Aller plus loin
- Dépôt du projet sur GitHub (92 clics)
- Dépôt de rage sur GitHub (45 clics)
- Specification (lien Google Documents) (21 clics)
# Point de détail
Posté par Moonz . Évalué à 6. Dernière modification le 30 octobre 2021 à 14:09.
Non, ça utilise X25519 (qui est un algorithme d’échange de clé sur la courbe elliptique Curve25519). Ed25519 c’est un algorithme de signature électronique ; il n’y a pas de signature dans age.
[^] # Re: Point de détail
Posté par Anonyme . Évalué à 2. Dernière modification le 30 octobre 2021 à 14:45.
Oui, bien vu. Si un modo peu corriger, ça serait super.
[^] # Re: Point de détail
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Erreur de lien
Posté par jcr83 . Évalué à 1.
Les deux liens dans le paragraphe "Critiques" sont identiques, le premier devrait être modifié.
[^] # Re: Erreur de lien
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# « Griefs contre OpenPGP et GPG »
Posté par gouttegd (site web personnel) . Évalué à 10.
Full disclosure : L’intérêt que je porte à OpenPGP est, je pense, bien connu et je suis contributeur occasionnel de GnuPG.
Certes. Et souvent exposés avec une bonne dose de mauvaise foi, et ce billet de Latacora ne fait pas exception. Il daterait d’une quinzaine d’années que je n’y trouverai rien à y redire, mais pour un billet écrit en 2019, difficile de voir autre chose que de la mauvaise foi quand l’auteur ignore délibérément tout ce qui a été fait dans le monde OpenPGP depuis dix ans.
La plupart des points dans ce billets, soit ont déjà été adressés (comme par exemple le fait qu’une clef OpenPGP serait forcément une clef RSA, volumineuse et obsolète, là où Age utilise des clefs X25519, lègères et modernes : les clefs ECC font partie du standard OpenPGP depuis le RFC 6637, en 2012, et toutes les implémentations courantes les prennent en charge — GnuPG le fait depuis 2014), soit sont en train de l’être avec la nouvelle révision du standard en préparation (comme le système d’authentification MDC, qui sera remplacé par un mécanisme AEAD conforme à l’état de l’art).
Certes, l’élaboration de la nouvelle révision du standard prend (beaucoup) plus de temps que ce qui était prévu. Mais c’est aussi le prix à payer quand on se soucie un minimum d’interopérabilité et de compatibilité avec l’existant, au lieu de balayer l’existant d’un revers dédaigneux de la main.
Ah, parce que oui, l’interopérabilité, ça compte, parce que contrairement à ce que prétend l’auteur du billet, non, GnuPG n’est pas la seule implémentation qui existe. Prétendre que « dépendre d’OpenPGP, c’est dépendre de GnuPG », c’est ignorer complètement Sequioa-PGP, OpenPGP.js, RNP, pour ne citer que les implémentations libres les plus importantes. Quand on sait que ProtonMail par exemple utilise OpenPGP.js, ou que Thunderbird utilise RNP, passer ces implémentations sous silence est assez fort de café.
--
Age est un projet intéressant, et un format standard de chiffrement débarrassé des contraintes historiques et du poids de l’existant répond certainement à un besoin. Mais que son auteur ne puisse le promouvoir autrement qu’en colportant des critiques dépassées et de mauvaise foi sur le standard et l’implémentation qu’il espère remplacer, ça me laisse un goût amer.
# X25519
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 7.
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é.
[^] # Re: X25519
Posté par Moonz . É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
[^] # Re: X25519
Posté par gouttegd (site web personnel) . Évalué à 7. Dernière modification le 02 novembre 2021 à 20:44.
Fournir aux développeurs une interface simple ne leur laissant pas la possibilité de faire n’importe quoi (ce qui en effet chaudement recommandé par tous les cryptologues aujourd’hui, on sent bien qu’à un moment ils ont en eu marre de se taper la tête contre les murs :D ) ne nécessite pas forcément de renoncer à l’agilité cryptographique et d’imposer un algorithme unique.
La bibliothèque Javascript SJCL par exemple offre l’interface la plus simple qui soit, impossible de l’utiliser de travers : deux fonctions, une pour chiffrer, une pour déchiffrer, prenant en paramètre les données à chiffrer ou déchiffrer et le mot de passe. Tous les choix algorithmiques sont effectuées par la bibliothèque elle-même, sans que le développeur ne puisse s’en mêler et donc faire des bêtises.
Pour autant, la bibliothèque et le format utilisé pour les données chiffrées permettent un minimum d’agilité cryptographique : l’algorithme de chiffrement, le mode d’opération, et les paramètres de l’algorithme de dérivation de clef ne sont pas fixés et peuvent être changés si besoin par les développeurs de SJCL (ou les développeurs d’une implémentation compatible) sans nécessiter un nouveau format ou la moindre rupture de rétro-compatibilité.
Ne pas supporter l’agilité cryptographique est un choix indépendant de la volonté (louable) de ne pas donner aux développeurs de quoi se tirer une balle dans le pied.
[^] # Re: X25519
Posté par gouttegd (site web personnel) . Évalué à 10.
L’agilité cryptographique (le fait de ne pas lier un protocole à un algorithme donné, mais d’offrir une sélection d’algorithmes) n’a plus trop la faveur des cryptologues de nos jours.
C’est essentiellement dû au fait qu’elle impose un mécanisme de négociation (les deux parties à la communication doivent se mettre d’accord sur les algorithmes à utiliser), et qu’un tel mécanisme est une source de complexité et donc de bogues (y compris des bogues résultant en des failles de sécurité). L’exemple typique avancé par les opposants à l’agilité cryptographique est TLS, qui a eu son lot de failles causées par cette étape de négociation.
(OpenPGP n’a à ma connaissance pas trop été affecté par ce genre de problèmes, mais le fait qu’il s’agisse fondamentalement d’un protocole hors-ligne simplifie pas mal la donne : contrairement à TLS ou SSH, la négociation ne se fait pas « en direct », mais seulement par l’intermédiaire des « préférences algorithmiques » portées par la clef du destinataire.)
Le credo de beaucoup de cryptologues est désormais : « Mettez tous vos œufs dans le même panier et surveillez ce panier comme la prunelle de vos yeux ! »
Pour ce que ça vaut, je ne suis personnellement pas convaincu par cette approche et pense que l’agilité cryptographique reste souhaitable (et je me réjouis que la future version d’OpenPGP n’y renonce pas), pour plusieurs raisons.
Ça veut dire quoi, « surveiller un algorithme » ? ce n’est pas en « surveillant » en algorithme que l’on va empêcher un cryptanalyste quelque part dans le monde d’y découvrir une faille. On peut bien demander à Matthew Green, Daniel Bernstein, Adi Shamir et Whitfield Diffie de monter la garde autour de la description de X25519 ou de AES, quelle « protection » ça apportera ?
L’idée est que si une faille dans l’algorithme sanctifié est découverte, on publie une nouvelle version du protocole avec un nouvel algorithme. Comme ça tout le monde bascule d’un coup vers le nouveau protocole et le nouvel algorithme sanctifié, et on ne se traîne pas un algorithme que l’on sait vulnérable. Un simple coup d’œil à l’histoire des transitions protocolaires (ne serait-ce que TLS, justement) me pousse à croire que penser qu’on peut forcer tout le monde à « basculer d’un coup » est complètement irréaliste.
En filigrane, derrière ce rejet de l’agilité cryptographique j’ai aussi l’impression de voir une très (trop ?) grande confiance dans les algorithmes choisis, comme si cette fois c’était la bonne, oui, on a eu des algorithmes qui se sont révélés mauvais par le passé mais là vraiment, X25519, Chacha20, Poly1305 c’est des bons, on peut vraiment miser dessus, la probabilité qu’on doive les changer un jour (et donc passer par une transition à une nouvelle version du protocole) est très faible. Si c’est le cas (et que ce n’est donc pas que mon impression), je ne suis pas sûr qu’une telle confiance soit opportune. On a justement eu suffisamment d’exemples d’algorithmes que l’on croyait à un moment très sûr jusqu’à ce qu’on réalise qu’ils ne l’étaient pas tant que ça… J’ai déjà évoqué récemment par ici le cas d’OCB2, que pendant près de quinze ans tout le monde pensait complètement sûr (« preuve de sécurité » à l’appui), jusqu’à ce qu’il se fasse démonter en seulement quelques mois…
[^] # Re: X25519
Posté par xryl669 . Évalué à 1.
Auriez vous un exemple où un algorithme a été cassé du jour au lendemain avec un retour à 0 de la sécurité de l'algorithme ?
Pour moi, et je me trompe probablement, lorsqu'une faille est découverte, la sécurité diminue, mais ne passe pas à 0 d'un coup. Par exemple, le SHA1 qui a été "forgé/dupliqué" une première fois par Google en 6 mois de calcul et qui est maintenant attaquable en 2 mois sur des fermes de serveurs. Ce n'est pas top, c'est sûr, mais ce n'est pas comme si un principe mathématique nouveau rendait le hash réversible.
Ce qui laisse du temps au développeurs de changer leur fusil d'épaule.
AMHA, l'agilité cryptographique c'est important, mais seulement sur un set très limité d'algorithme et qui reste limité (genre 3 algos possibles, si un devient moins fiable, on le "deprecate" en le remplaçant par un autre et qui ne peut être utilisé que pour le décodage).
[^] # Re: X25519
Posté par gouttegd (site web personnel) . Évalué à 9.
J’ai donné l’exemple de OCB2, qui depuis son introduction en 2004 était considéré parfaitement sûr. Puis en 2018, deux attaques coup sur coup : en octobre, une première attaque montre qu’on peut forger des messages (l’algorithme ne garantit pas l’authenticité, contrairement à ce qu’il devrait devrait — en soi c’est déjà une faille énorme, qui aurait été suffisante pour justifier un retrait immédiat de l’algorithme) ; le mois suivant, une autre attaque s’appuie sur la première pour pour casser la confidentialité et permettre de récupérer le texte clair (plaintext recovery attack). Cinq mois plus tard, un papier de synthèse ferme le ban pour ceux qui seraient lents à comprendre : OCB2 est cassé, kaput, les attaques sont praticables et effectives, il ne faut en aucun cas l’utiliser.
(La bonne nouvelle, c’est que quasiment personne n’utilisait OCB2 de toute façon, à cause des brevets qui pesaient dessus…)
Juste parce que certains algorithmes ont effectivement été lentement érodés avant qu’on ne puisse les considérer comme effectivement vulnérables ne veut pas dire que ce sera systématiquement le cas, et miser là-dessus me semble très risqué.
Absolument d’accord. Le problème du rejet de l’agilité cryptographique, c’est qu’on passe d’un extrême à l’autre. Avant c’était la foire et on acceptait 72 algorithmes dans le protocole (y compris des perles comme MD5, RC4, 3DES, etc.), maintenant c’est un algorithme epicétou !
On peut supporter l’agilité cryptographique tout en acceptant seulement une petite poignée d’algorithmes soigneusement choisis.
[^] # Re: X25519
Posté par Moonz . Évalué à 4.
OCB2 n’a jamais vraiment été regardé avec intérêt. Jusqu’en 2013 la famille OCB était virtuellement non-existante à cause des brevets, et c’est OCB1 qui a été standardisé à l’IETF et est entré dans la compétition CAESAR.
Le seul exemple d’algorithme largement utilisé qui a pris beaucoup de monde de court, c’est SHA-1, mais on quand même parle de 4 ans (2015-2019) entre la fumée (collision) et le feu (attaque pré-image).
[^] # Re: X25519
Posté par Anonyme . Évalué à 3.
Je pense que l’idée est plutôt que le jour où ces algorithmes sont défaillants, on change le protocole pour en forcer d’autres et on laisse la transition à la charge de l’utilisateur.
Dans le papier blanc de WireGuard, par exemple, l’auteur dit (l’emphase est de moi) :
Pour TLS, c’est à peu prêt pareil, on fera un TLS 1.4 et on migrera.
[^] # Re: X25519
Posté par Anonyme . Évalué à 3.
Je viens de relire ton commentaire et c’est ce que tu souligne dans ton second point
[^] # Re: X25519
Posté par gouttegd (site web personnel) . Évalué à 10. Dernière modification le 04 novembre 2021 à 02:27.
J’ai déjà dit ce que je pensais de la faisabilité de cette approche. Si le futur me donne tort, je serai le premier à en être content, mais je n’y crois guère.
Il s’agirait quand même de ne pas tout mettre sur le dos de l’agilité cryptographique.
Parmi toutes les attaques contre TLS, moi je n’en compte que deux qui ont été permises par l’agilité cryptographique : FREAK et LOGJAM, qui exploitent des failles dans la procédure de négociation des algorithmes pour forcer l’usage d’algorithmes ridiculement faibles.¹
Les autres attaques ? Voyons voir :
Il est certain que la complexité générale de TLS est à l’origine de certaines de ces attaques. Mais il n’y a pas que l’agilité cryptographique qui rend TLS complexe ! CRIME et Heartbleed par exemple sont dûes à des fonctionnalités accessoires (la compression pour CRIME et l’extension Heartbeat pour Heartbleed) — des fonctionnalités apparemment peu usitées de surcroît, ce qui rend leur présence dans un protocole de cryptographie assez contestables. Et d’autres protocoles que TLS supportent l’agilité cryptographique sans avoir un tel « palmarès » d’attaques (par exemple SSH).
On peut aussi noter que l’agilité cryptographique a permis d’offrir des contre-mesures immédiates à plusieurs de ces attaques, sans devoir attendre une mise à jour du protocole ou des implémentations (et c’est heureux, parce que vous avez vu le temps qu’il faut pour publier une nouvelle version de TLS ou pour avoir des implémentations à jour ? en 2015 on trouvait encore des serveurs et des clients qui ne supportaient pas TLS 1.2, publié en 2008…).
Par exemple, à la publication de BEAST (attaque contre CBC) en 2011, on a pu conseiller aux sysadmins de privilégier RC4 (qui n’était pas vulnérable, s’agissant d’un algorithme de chiffrement en flux). Deux ans plus tard, les attaques contre RC4 ont commencé à se faire un peu trop pressantes, mais ça a donné un répit de deux ans aux développeurs de bibliothèques TLS pour, soit implémenter des contre-mesures contre BEAST, soit (encore mieux) implémenter TLS 1.1+ (qui n’est plus vulnérable à BEAST), soit implémenter d’autres modes de chiffrement que CBC, voire les trois à la fois.
¹ Ce qui n’aurait posé aucun problème si serveurs et clients n’avaient pas continué à supporter les algorithmes ridiculement faibles en question, ce qui me ramène à un point avancé dans un autre message : il n’y a aucune raison pour que « agilité cryptographique » signifie forcément « supporter tous les algorithmes possibles et imaginables, même les plus pourris » — on peut être favorable à l’agilité sans pour autant se priver d’exclure les algorithmes cassés ou en passe de l’être.
[^] # Re: X25519
Posté par gouttegd (site web personnel) . Évalué à 4.
Euh, non. TLS 1.3 offre toujours l’agilité cryptographique.
La liste des algorithmes utilisables (cipher suites) a été considérablement réduite (en particulier, toutes les suites sans mode AEAD ont été éjectées), mais le principe même d’avoir une liste d’algorithmes dans laquelle choisir ceux à utiliser est toujours là et le protocole est toujours ouvert à l’introduction d’algorithmes non-listés dans le RFC original (par exemple les algorithmes russes GOST).
À ma connaissance le seul endroit où une forme d’agilité a été supprimée est la représentation des points sur les courbes elliptiques. TLS 1.2 autorisait plusieurs formats pour représenter ces points (d’où la nécessité de les négocier entre client et serveur, comme pour les algorithmes eux-mêmes), TLS 1.3 impose un format unique.
[^] # Re: X25519
Posté par Anonyme . Évalué à 2.
Sans possibilité de configuration*
C’est la même chose pour WireGuard, et pratiquement la même chose pour TLS 1.3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.