Dans les actualités Fortran, on abordera en particulier la troisième édition de la conférence internationale Fortran, la sortie officielle du nouveau compilateur Flang dans LLVM et les actualités du gestionnaire de paquets fpm. Et comme c'est bientôt les vacances, on terminera par une section consacrée à Fortran dans la culture populaire, où l'on apprendra entre autres que le Nostromo avait un neuvième passager…

Sommaire

• Appel à contributions pour FortranCon 2025
  • Dates limites
• Sur le front des compilateurs
  • Compilateurs opérationnels
    • Flang (LLVM)
    • Intel ifx
    • GFortran (GCC)
  • En gestation
  • Fedora ou F comme Fortran ?
• Communauté Fortran-lang
  • Projets Fortran-lang
    • fpm
  • Quelques projets divers
• Fortran et culture populaire
  • Alien
  • Fortran dans les dessins animés américains

Appel à contributions pour FortranCon 2025

FortranCon 2025 est la troisième édition de la conférence internationale sur le développement et l'utilisation du langage de programmation Fortran, et aura lieu les 4 et 5 novembre 2025. Avec cette conférence, nous avons l'intention de rassembler les développeurs actifs du projet Fortran dans tous les domaines : les développeurs de bibliothèques et d'outils ainsi que les personnes utilisant Fortran pour développer des applications scientifiques, afin de partager leur expérience et d'échanger des idées. L'événement est organisé sur Zoom grâce aux contributions de la communauté pour la communauté.

Le discours d'ouverture sera prononcé par John Reid, membre actif du comité Fortran de l'ISO/IEC JTC1/SC22/WG5 (et animateur du comité de 1999 à 2017). C'est également l'un des auteurs du livre de référence Modern Fortran explained, dont la sixième édition (couverture orange) inclut Fortran 2023.

Les vidéos des présentations des éditions 2020 et 2021 sont toujours en ligne sur la chaîne YouTube FortranCon.

Dates limites

• Inscription (gratuite) : 15 octobre 2025.
• Premier appel à résumés : 1er août 2025 (décisions envoyées avant le 30 août 2025).
• Deuxième appel à résumés : 1er septembre 2025 (décisions envoyées avant le 30 septembre 2025).

Sur le front des compilateurs

Compilateurs opérationnels

Flang (LLVM)

Dans LLVM 20.1, sorti en mars 2025, flang-new a été rebaptisé flang et remplace son prédécesseur du même nom. Il s'agit donc du lancement officiel de ce nouveau compilateur soutenu par NVIDIA et le Département de l’Énergie américain, après sept ans de développement. Un article très complet du blog LLVM relate cette longue aventure :

• David Spickett, LLVM Fortran Levels Up: Goodbye flang-new, Hello flang!, 11 mars 2025.

La doc de Flang présente même une pierre de Rosette pour les gens connaissant le C ou le C++ et souhaitant débuter en Fortran.

Intel ifx

Intel ifx (basé sur LLVM) est actuellement en version 2025.2.0, avec en particulier quelques améliorations du côté Fortran 2023 et OpenMP 6.0, par rapport à la 2025.1.0 qui améliorait également ces deux points.

GFortran (GCC)

GFortran est en version 15.1. Attention, les fichiers .mod générés par GFortran 15 ne sont pas compatibles avec les versions antérieures. Si vous ne savez pas de quoi je parle, les .mod c'est un peu l'équivalent des fichiers headers .h en C, mais en pire puisque ce sont des fichiers binaires pas normalisés, donc pas interopérables entre les différents compilateurs Fortran, voire comme ici entre différentes versions. Bref, pas glop !

Parmi les six projets GCC du GSoC 2025, on en trouve un pour améliorer la prise en charge par GFortran de certaines fonctionnalités des normes Fortran 2018 et 2023. Le compilateur libre a également reçu 360 k€ de la Sovereign Tech Agency allemande, en particulier pour offrir un support direct des coarrays (co-tableaux) pour le calcul parallèle sur systèmes à mémoire partagée (pour l'instant il est nécessaire d'installer la bibliothèque OpenCoarrays pour les utiliser avec GFortran).

En gestation

Le développement du compilateur LFortran continue. Il s'approche tranquillement de la version beta, compilant déjà huit bibliothèques Fortran matures sur les dix définies pour ce jalon. On notera d'ailleurs que parmi les cinq projets de la communauté Fortran-lang du GSoC 2025, un projet a pour objectif de réussir à compiler le gestionnaire de paquets fpm avec LFortran. Une bonne façon de faire progresser le compilateur !

Fedora ou F comme Fortran ?

Une des meilleures distributions Linux pour faire du Fortran est peut-être Fedora. On trouve en effet directement dans ses dépôts pas moins de trois compilateurs Fortran libres en versions récentes : GFortran (GPL), Flang (licence Apache) et LFortran (licence BSD). Quand à Intel ifx, on pourra facilement l'installer par exemple dans un environnement Conda (paquet ifx_linux-64). Et avec la Fedora Rawhide, c'est bien sûr encore plus saignant (bleeding edge) au niveau des versions !

Communauté Fortran-lang

Projets Fortran-lang

fpm

Le gestionnaire de paquets Fortran fpm est disponible en version 0.12 depuis le 18 mai 2025. Parmi les nouveautés, on notera :

• un fichier compile_commands.json exporté par défaut à chaque fois que l'on construit un projet avec fpm, ce qui facilitera son intégration avec d'autres outils, en particulier les IDE.
• Deux nouveaux métapackages disponibles : BLAS/LAPACK et NetCDF.
• La possibilité de générer des bibliothèques partagées, et non plus uniquement statiques.

Du côté des greffons, on citera fpm-modules et fpm-deps qui permettent de visualiser les dépendances d'un projet fpm à l'aide d'outils tels que Mermaid ou Graphviz.

Quelques projets divers

• Fortitude 0.7.3 : un linter Fortran sous licence MIT, écrit en Rust et installable via Python.

• Seer : une interface graphique pour gdb pour Linux, qui prend en charge de nombreux langages, dont Fortran. Licence GPL 3.0.

• Codee commercialise un analyseur de code Fortran / C / C++ et un formateur de code Fortran. Ce dernier peut néanmoins être utilisé gratuitement pour un usage personnel. « Codee se distingue en tant que plateforme de développement Fortran, C et C++, en favorisant la correction du code, la modernisation, la sécurité, la portabilité et l'optimisation afin d'aider les développeurs à fournir des logiciels rapides, faciles à maintenir et fiables, conformes aux normes de l'industrie. » Codee vient de sortir en version 2025.3.

Fortran et culture populaire

Alien

Comme vous le savez peut-être, le Nostromo est le vaisseau spatial du film Alien (1979). Lors de l'atterrissage sur la lune Acheron LV-426, l'ordinateur de bord affiche un modèle 3D de son relief. Sur cet extrait sur YouTube, vous pouvez le voir plusieurs fois à partir de l'instant 2:28. Ce modèle est présenté par son auteur dans l'article suivant :

• Alan Sutcliffe, "Landing the Nostromo", Creative Computing Magazine, vol. 7, n°6, p. 48-54, juin 1981.

Le code ne faisait que 14 pages de code FORTRAN et son auteur explique :

Le matériel utilisé était un Prime 300 connecté à un FR 80 de III (Information International, Inc.) qui peut tracer directement sur pellicule. Le logiciel d'animation Frolic, développé par C. Emmett, tournait sur ce système dans les laboratoires du SRC à Oxfordshire.

Mon programme était écrit en FORTRAN avec des appels aux sous-routines Frolic.

Années 70 obligent, le graphisme n'est pas sans rappeler le signal du pulsar CP1919 tracé informatiquement par Harold D. Craft Jr dans sa thèse soutenue en 1970 et popularisé par Peter Saville sur la pochette de l'album Unknown Pleasures, dont je vous avais déjà parlé. Quarante-six ans après la sortie du film Alien, on pourra s'amuser de constater que n'importe quelle voiture actuelle a un écran couleur bien plus high-tech que celui du Nostromo ! Mais dix ans avant, le premier alunissage avait eu lieu avec une informatique et une électronique qui semblent aujourd'hui rudimentaires. C'est que se déplacer est avant tout un problème de mécanique (éventuellement céleste). Côté déplacement, le Nostromo reste quand même très largement en avance sur les starships actuels.

Fortran dans les dessins animés américains

Le langage semble avoir laissé des traces, plutôt bienveillantes, chez les (vieux) étudiants américains :

• Dans la série d'animation Futurama, Olde Fortran est une marque de liqueur de malt (bière forte) consommée par le robot Bender, une sorte de boisson énergisante pour lui. On y voit aussi des jackpots Wheel of Fortran (roue de la fortune… Algorithme Monte Carlo ?).
• Dans Les Simpson, épisode « L'homme qui vint pour être le dîner » (2015), un extraterrestre dit à 1:23 :

« En tant que jeunes choses insignifiantes, nous sommes éduqués dans la sagesse de l'univers. Physique, mathématiques, FORTRAN - le plus grand des langages de programmation ! »
(“As young thinglings, we are schooled in the wisdom of the universe. Physics, mathematics, FORTRAN - the greatest of the programming languages!”)

Il était une fois un petit ESP32, installé dans une cave, qui voulait communiquer avec son copain sur le toit pour envoyer des données par 4G. Il parlait peu, donc il pouvait utiliser la norme radio LoRa. Elle est à bas débit, mais permet une portée bien plus grande qu’une modulation classique. Le problème, c’est qu’il parlait en clair, et que n’importe qui pouvait écouter ou pire : injecter de fausses données, voire corrompre le serveur distant.

Le protocole de communication à la mode est celui de Signal, utilisé aussi par WhatsApp et Messenger. Un autre protocole en vogue est WireGuard, dont l’objectif est d’offrir un VPN léger pour Linux, en s’appuyant sur un ensemble restreint de briques cryptographiques modernes et fortement recommandées, qui ne sont plus laissées au choix de l’utilisateur.

L’idée était donc de trouver une implémentation de ce type pour l’embarqué. Eh bien, je n’ai presque rien trouvé.

Sommaire

• Briques de base
• Le chiffrement symétrique
• Le hash
• “Password hashing” ou la création de clef à partir de mot de passe
• Chiffrement à clef publique
• Générateur d’aléatoire
• Signature
• Serial Guard, le protocole de communication
• Le rejeu
• Durée de session
• Envoi d’un seul message
• Travail en cours

Briques de base

TLS est la référence absolue pour tous les algos, mais c’est à vous de faire votre choix. Libsodium est une implémentation des derniers algos recommandés et fait le choix pour vous. Ces deux bibliothèques sont énormes et sont optimisées pour PC. Un professeur de cryptographie a écrit une série de tweets qui contient une petite lib qui reprend les algorithmes de libsodium en version auditable (https://tweetnacl.cr.yp.to/). Mais elle est lente.

Une autre personne écrit ce que je cherche : Monocypher. C’est un fichier .c avec les algo principaux de libsodium et qui compile en pur C sans dépendance ! C’est parfait pour mon besoin.

Cette bibliothèque fournit uniquement les briques de base, on est très loin d’un protocole Signal. Quand on parle de cryptographie, on pense à AES pour le chiffrement symétrique, à RSA pour le chiffrement à clef publique et la signature, aux hashs SHA1 ou SHA512 pour un hash de qualité cryptographique. Les propriétés nécessaires sont fascinantes mais cela ne dit pas comment bien les utiliser ensuite.

Le chiffrement symétrique

Il s’agit de chiffrer un bloc avec une clé de taille fixe. Le représentant le plus connu est AES, avec des clés de 128 ou 256 bits. On a un bloc, on a une clé, et on obtient un bloc plus ou moins aléatoire. AES utilise des modes (GCM, XTS, …) pour renforcer le mélange et garantir la sécurité selon différents contextes.

Ici, l’algorithme recommandé est ChaCha20. Pas besoin de mode externe : tout est prévu dans l’algorithme de base.

Au déchiffrement, la brique ne se pose pas de question : si la donnée a été altérée, le résultat le sera aussi.Il faut donc ajouter un protocole d’authentification, qui utilise la même clé et un hash pour vérifier l’intégrité. Les algorithmes classiques sont MAC, HMAC, mais il est facile de faire une erreur dans leur utilisation.

Monocypher utilise Poly1305 pour authentifier le message (AEAD – Authenticated Encryption with Associated Data). Son API combine XChaCha20 et Poly1305, ce qui évite de se poser des questions : en cas de modification du message chiffré, la fonction de déchiffrement renvoie une erreur explicite.

Cette fonction nécessite un NONCE ("Number used once"), qui doit être différent à chaque appel.

Le hash

Un hash prend un bloc de données, fait une grosse salade et rend un chiffre de taille fixe avec de bonnes propriétés crypto. Le but est d’avoir une empreinte de taille fixe pour un bloc de données, et qu’il soit impossible de forger un hash identique en modifiant un peu les données d’origine. En gros.

Le hash recommandé est BLAKE2b : “as secure as SHA-3 and as fast as MD5”. Il fait 256 ou 512 bits.

“Password hashing” ou la création de clef à partir de mot de passe

Lorsqu’un mot de passe est saisi, il n’est jamais utilisé tel quel : il est d’abord transformé en une valeur de taille fixe via une fonction de hachage. Pour contrer les attaques par force brute, on a commencé par appliquer des centaines d’itérations de SHA1, avant d’adopter des fonctions de hachage volontairement lentes, comme bcrypt ou scrypt. Le but étant justement d’éviter qu’elles soient rapides, contrairement aux fonctions de hachage classiques.

Aujourd’hui, Argon2 est recommandé.

Chiffrement à clef publique

L’image est souvent celle d’un cadenas ouvert : n’importe qui peut fermer le cadenas, mais seul le possesseur de la clef peut l’ouvrir. RSA a été le premier algorithme inventé avec cette propriété. Aujourd’hui, la mode est aux courbes elliptiques avec X25519.

La fonction principale est basée sur l’échange Diffie-Hellman (DH). C’est le truc magique de la crypto asymétrique.

DH(Clef publique de A, Clé privée de B) = DH(Clef publique de B, Clé privée de A) = N

Sans une clef privée, il est cryptographiquement impossible de retrouver N.

Comment créer une clef privée ? C’est simplement 32 octets très aléatoires. Toute la sécurité dépend de cela. On se rappelle de la faille Debian utilisant un générateur prévisible en 2008.

Générateur d’aléatoire

Pour faire de la cryptographie sérieusement, il faut un vrai générateur aléatoire de qualité cryptographique. Monocypher, par exemple, n’en fournit pas, car cela dépend trop du matériel utilisé. C’est donc à vous d'en fournir un correct.

Ne surtout pas utiliser random() ou rand() : ces fonctions ne sont pas prévues pour la sécurité. Elles offrent souvent à peine 32 bits d’entropie, ce qui signifie qu’elles peuvent générer des valeurs qui tournent en boucle après seulement 4 milliards de cas, ce qui est trivial à explorer pour un attaquant moderne.

Un bon générateur s’appuie sur des sources d’entropie, autrement dit, des phénomènes imprévisibles : le bruit du système, les délais entre événements, la température, etc. Ensuite, ces sources sont mélangées (souvent via un gros hash) pour produire des nombres avec des propriétés statistiques solides.

Par exemple, Linux collecte plein de métriques internes (activité réseau, mouvements de la souris, etc.) pour alimenter son générateur aléatoire /dev/urandom.

Côté matériel, certaines plateformes proposent un vrai générateur physique : il peut mesurer le bruit électrique à travers une diode via un convertisseur analogique-numérique (ADC), ou encore exploiter les légères variations de vitesse d’oscillateurs internes (anneaux d’inverseurs), qui sont ensuite mélangées avec des circuits comme des LFSR combinés via XOR.

Utilisez le générateur cryptographique fourni par votre plateforme (par exemple getrandom(), arc4random(), ou un TRNG matériel si vous êtes en embarqué).

Il ne faut pas se créer son propre générateur sans savoir exactement ce que l’on fait. Le pire étant de réutiliser des données (des clefs par exemple) pour générer d’autres nombres. On crée ainsi une énorme dépendance entre eux, qui n’ont plus rien d’aléatoire.

Les dernières failles des imprimantes Brother proviennent du fait que les mots de passe d’administration sont dérivés de leur numéro de série (!).

Signature

On a un bloc de données, on signe avec une clef privée, on vérifie la signature avec la clef publique.

Monocypher propose EdDSA.

Serial Guard, le protocole de communication

Il ne faut pas créer sa propre cryptographie, c’est trop facile de se tromper. C’est pourtant exactement ce que j’ai fait. La suite peut donc contenir des erreurs. L’idée est de créer un protocole léger de communication. Si des experts passent par là et voient une horreur, qu’ils n’hésitent pas à crier.

On a maintenant les blocs de base. Et il faut maintenant les agencer comme il faut. On veut que A communique avec B (Alice et Bob), sans que E puisse comprendre les messages, insérer des messages, modifier des messages, rejouer des messages, récupérer les messages dans le futur s’il a tout enregistré et récupérer les clefs privées.

Dans le monde de l’embarqué « simple », on communique avec des read et des write sur lien série. L’idéal est d’avoir à peu près la même API.

Il faut réduire au minimum l’échange d’informations préalable pour être le plus léger possible.

Je laisse de coté le "framing", c'est à dire la mise en paquet pour être envoyé sur un lien physique. Un lien série envoie des octets, serialguard fonctionne par paquets d'octet. Il faut reconstituer un paquet avant de l'envoyer dans la bibliothèque.

La base est d’avoir une clef privée chacun, à longue durée de vie. Cela permet de s’authentifier selon le principe : si c’est toujours la même clef depuis l’installation, c’est toujours le même pair : TOFU.

Si on a besoin de faire mieux, il faudrait qu’une « clef de confiance » signe cette clef. Mais on entre dans les méandres complexes d’une public key infrastructure, des certificats ou des web of trust type GPG.

Pour pouvoir tout de même changer une clef privée à long terme, tout en ayant de la sécurité pour éviter les man-in-the-middle, il faut garder un secret partagé dans tous les pairs. Cela peut être très compliqué sur un réseau de serveurs, mais ici, chaque boîtier est programmé au même endroit.

Il s’agit simplement d’un nombre de 32 octets aléatoire partagé par tous. C’est nommé pompeusement pre-shared key (PSK).

Il faudra éviter de la laisser traîner dans le code source.

Une clef de session est une clef temporaire, renouvelable. L’idée est d’utiliser la cryptographie asymétrique pour se mettre d’accord sur une clef symétrique.

Si on utilise le nombre généré par Diffie-Hellman (DH) directement, il est unique par pair de clefs privées : ce n’est pas top. On pourrait échanger des nombres aléatoires pour se mettre d’accord sur une clef symétrique, mais je veux limiter les échanges au minimum.

Pour cela, je vais utiliser une clef de session asymétrique, qui est l’invention du protocole Signal. Une fois la clef symétrique générée, la clef privée éphémère est jetée. Il sera impossible ensuite de déchiffrer la session, même dans le futur.

On commence donc par un échange de 2 clefs publiques : l’une à durée de vie longue et l’autre éphémère.
On croise les 8 clefs (2 publiques et 2 privées de chaque côté) dans 3 échanges DH, on trie les nombres pour avoir le même ordre des 2 côtés, et le résultat est donné à la fonction de hachage avec la PSK.

On a ainsi notre clef de session symétrique.

Le rejeu

Tant que la session est active, l’envoi d’un message précédent reste valide. Pour éviter cela, un NONCE est utilisé dans le chiffrement symétrique. C’est un nombre fourni quelconque mais qui ne doit jamais être identique d’un paquet à l’autre. Il peut être transmis avec le paquet, mais cela prend de la place.

J’ai choisi d’utiliser un simple compteur, cela évite de devoir se rappeler les NONCE passés pour éviter le rejeu.

Les liaisons n’étant pas fiables, un paquet peut être corrompu : il faut pouvoir décoder le paquet suivant. J’ai simplement choisi de tester les 10 nombres successifs en cas d’erreurs, avant d’échouer.

Durée de session

Une session doit être limitée en temps ou en quantité d’informations transmises. Il faut trouver un événement symétrique des 2 côtés pour redéclencher un handshake. J’ai laissé ce point à l’application. Cela pourrait être inclus dans le protocole réseau de plus haut niveau.

Envoi d’un seul message

Ce schéma ne couvre pas le cas d’envoi d’un seul message.

Dans l’Internet des objets, on pousse un message dans MQTT et on ne s’attend pas à une réponse. Cela serait bien plus pratique de pouvoir le faire. Il faut pouvoir faire l’envoi sans handshake préalable. Mais il faut tout de même envoyer les clefs publiques, ce qui prend de la place.

Le système a besoin de la clef publique du serveur et du PSK, et tout le reste est fourni en plus du chiffré (NONCE, clef publique, et clef publique éphémère) dans le message envoyé.

La différence est qu’il n’y a que 2 DH, et pas de clef éphémère du côté serveur.

Travail en cours

C’est encore un travail en cours. Il manque des tests sur le terrain et l’évaluation des performances sur plusieurs plateformes.