- Le chiffrement homomorphe complet (FHE) est une technologie qui permet d’effectuer des calculs directement sur des données chiffrées, sans les déchiffrer
- Aujourd’hui, le FHE reste limité par une faible applicabilité pratique, un ralentissement des calculs de 1 000x à 10 000x et une augmentation de l’espace de stockage de 40x à 1 000x
- Mais les algorithmes FHE récents enregistrent des gains de vitesse multipliés par 8 chaque année, et pourraient bientôt devenir praticables pour le cloud computing, l’inférence de LLM ou encore les smart contracts sur blockchain
- Si le FHE se généralise, il pourrait provoquer une transformation industrielle où la confidentialité des données devient le réglage par défaut dans l’ensemble de l’environnement informatique
- L’article couvre de manière approfondie les concepts clés comme les cryptosystèmes sur réseau, LWE, le bootstrapping, ainsi que l’histoire des algorithmes FHE, des exemples d’implémentation concrets et l’évolution des performances
Introduction : qu’est-ce que le chiffrement homomorphe complet ?
- Le chiffrement homomorphe complet (Fully Homomorphic Encryption, FHE) est une méthode qui permet d’exécuter des opérations arbitraires sur des textes chiffrés, sans déchiffrement, c’est-à-dire de calculer directement sur des données chiffrées
- Autrement dit, un serveur peut calculer une requête et son résultat sans jamais connaître le texte en clair
- Cette technologie est déjà en cours d’adoption dans plusieurs systèmes du monde réel
Potentiel et limites du FHE : la « loi de Moore du FHE »
- Le FHE permet de conserver les données chiffrées en permanence sur le réseau, ce qui ouvre la voie à une confidentialité totale en éliminant à la source le risque de fuite de données
- Malgré cela, son déploiement pratique reste limité aujourd’hui, car les opérations sur texte chiffré sont 1 000 à 10 000 fois plus lentes que celles sur texte en clair, et le stockage augmente d’environ 40 à 1 000 fois, soit une dégradation massive des performances
- La situation rappelle les débuts d’Internet dans les années 1990
- Mais le FHE progresse récemment à un rythme de 8x par an, ce qui laisse penser qu’il entrera bientôt dans plusieurs domaines d’usage concrets
Point de bascule : la praticabilité du FHE approche
- Si cette accélération spectaculaire se poursuit, le FHE pourrait devenir utilisable dans des domaines comme :
- le cloud computing chiffré
- l’inférence de LLM chiffrée
- les smart contracts blockchain avec garanties de confidentialité
- Une telle évolution pourrait bouleverser en profondeur le modèle économique de l’Internet fondé sur la collecte des données des utilisateurs
- Le FHE pourrait entraîner une transition fondamentale d’un Internet où « la surveillance est la norme » vers un Internet où « la confidentialité est la norme »
Le talon d’Achille de la sécurité des données et la réponse du FHE
- Les données existent sous trois états (au repos, en transit, en cours d’utilisation), et c’est souvent dans l’état « en cours d’utilisation » qu’elles sont déchiffrées et deviennent vulnérables
- Cloud, employés internes, hackers, CPU vulnérables : tous peuvent potentiellement accéder aux données en clair présentes en mémoire
- La plupart des grandes fuites de données surviennent elles aussi lorsque les données sont « en cours d’utilisation » ou « au repos »
- Le FHE maintient les données chiffrées pendant tout leur cycle de vie et élimine ainsi ces vulnérabilités à la racine
Définition d’un calcul à confidentialité totale
- Dans l’environnement idéal, les données restent chiffrées au stockage, pendant la transmission et pendant l’utilisation (le calcul)
- Par exemple, le serveur ne voit jamais la requête en clair, reçoit une requête chiffrée et ne renvoie qu’un résultat chiffré
- Seul l’utilisateur peut déchiffrer ce résultat
Comment fonctionne le FHE : structure mathématique et concepts
- Le terme « homomorphe » repose sur une transformation mathématique qui conserve la même structure, à la manière d’une transformation de Fourier
- Le FHE transforme bidirectionnellement l’espace des textes en clair et celui des textes chiffrés, de sorte que le déchiffrement du résultat d’une opération sur texte chiffré est identique au résultat de l’opération sur texte en clair
- Ces transformations s’appuient principalement sur les cryptosystèmes sur réseau et le LWE (Learning With Errors)
- Les cryptosystèmes sur réseau reposent sur des problèmes vectoriels en très grande dimension, réputés difficiles à résoudre même pour un ordinateur quantique (résistance quantique)
- Le LWE consiste à inverser un système linéaire bruité, un problème considéré comme irréaliste à casser en pratique
Gestion du bruit et bootstrapping
- Dans le FHE, le bruit interne au texte chiffré augmente à mesure que les opérations s’enchaînent
- Il croît linéairement pour l’addition et exponentiellement pour la multiplication, jusqu’à rendre le déchiffrement impossible
- La technologie clé pour résoudre ce problème est le bootstrapping, qui consiste à rechiffrer le texte chiffré avec une « nouvelle clé publique » afin de réinitialiser le niveau de bruit
- Ce processus reste le principal goulet d’étranglement des systèmes FHE, mais il s’améliore rapidement d’année en année
Autres composants clés du FHE
- Relinéarisation (relinearization) : processus qui corrige l’augmentation quadratique du degré de clé après une multiplication pour le ramener à un degré linéaire
- Modulus switching : technique consistant à réduire le module du texte chiffré pour mieux gérer le bruit
En plus de cela, de nombreuses autres techniques continuent d’être proposées au fil des avancées algorithmiques
Classification des schémas de chiffrement homomorphe (HE) et exemple Python
- Chiffrement homomorphe partiel (Partial HE) : ne prend en charge qu’une seule opération (par exemple, le chiffrement de Paillier ne prend en charge que l’addition)
- Chiffrement homomorphe limité (Somewhat HE) : prend en charge l’addition et la multiplication, mais avec une limite sur le nombre de multiplications successives
- Chiffrement homomorphe complet (FHE) : prend en charge sans limite l’addition et la multiplication, avec garantie de complétude de Turing
Un exemple de chiffrement de Paillier implémenté en Python permet de saisir intuitivement le principe du chiffrement homomorphe partiel
Histoire du FHE et « loi de Moore du FHE »
- 1978 : première apparition du concept d’« homomorphisme pour la confidentialité »
- 2009 : première réalisation du FHE par Craig Gentry (thèse de doctorat)
- 2011 : première implémentation, avec 30 minutes par bit (extrêmement lent)
- À partir de 2013 : réduction du bootstrapping à quelques millisecondes
- 2017 : prise en charge des approximations en virgule flottante avec CKKS, ouvrant la voie à une adoption plus sérieuse en ML/IA
Les algorithmes FHE se sont améliorés d’un facteur 8 par an depuis 2011, passant d’un surcoût initial de 10¹⁰ à un niveau récent de 10³ à 10⁴
Des publications récentes ont réduit de 1 000x le débit de multiplication FHE et de 10x la latence, et l’association avec l’accélération matérielle pourrait encore apporter plus de 1 000x d’amélioration supplémentaire
Un avenir où le chiffrement devient la norme
- Les grandes fuites de données sont une réalité inévitable
- Si, grâce au FHE, le serveur peut seulement calculer sur des données chiffrées sans disposer de la clé de déchiffrement, cela pourrait définir un nouveau standard de protection de la vie privée
- La technologie n’est pas encore pleinement praticable dans tous les domaines, mais elle progresse à une vitesse remarquable chaque année
- Entre l’exigence croissante des utilisateurs en matière de confidentialité et le durcissement de la réglementation, le FHE devrait à terme devenir un standard de la majorité du cloud computing
- Le calcul sur Internet du futur évoluera vers un état toujours chiffré
Années 2010 : HTTPS comme réglage par défaut
À l’avenir : une époque où le FHE devient le réglage par défaut
Références et ressources complémentaires
- FHE Reference Library : compilation complète de ressources académiques
- Thèse de doctorat de Craig Gentry, 2009 : point de départ du FHE
- Vitalik Buterin : analyse approfondie du FHE
- Communauté : FHE.org (hub centré sur les développeurs)
- GitHub: awesome-he : collection de projets liés au chiffrement homomorphe
1 commentaires
Avis Hacker News
Je précise d’emblée que j’aime beaucoup la FHE et la cryptographie. La FHE devient de plus en plus rapide, mais tant qu’elle dépendra du bootstrapping, elle ne pourra pas rattraper la vitesse de calcul sur des données en clair. Le surcoût d’environ 1000x ou plus dû au bootstrapping est fondamentalement inévitable, et c’est lorsqu’on a compris qu’il était impossible de l’accélérer davantage qu’on a commencé à parler d’accélération matérielle. Mais à une époque où toute la puissance de calcul part dans les LLM, ce n’est pas simple. Si l’on pense au coût par token quand on calcule avec de la FHE, il y a très peu de chances que ce soit réaliste à moins d’être bien en dessous de 1000x. Pour la protection de la vie privée, le confidential computing est pour l’instant la seule alternative vraiment pratique. Je n’aime pas l’idée de devoir faire confiance au matériel, mais c’est ce qu’on a de mieux
Il y a une raison encore plus fondamentale qui rend la FHE difficile à utiliser pour des calculs arbitraires. Certains types d’opérations voient leur complexité exploser de façon anormale sur des chiffrés par rapport au clair. Dans le cas d’une recherche en base de données, on est en O(log n) en clair, mais en recherchant avec une clé chiffrée on passe en O(n). C’est pourquoi une recherche Google entièrement homomorphe est essentiellement irréalisable. En revanche, l’inférence de DNN entièrement homomorphe peut être différente
Même sans bootstrapping, la FHE ne pourra pas être aussi rapide que le calcul en clair. Les chiffrés sont environ 1000 fois plus gros que les données en clair. Cela signifie qu’il faut bien plus de bande passante mémoire et bien plus d’opérations. Cet écart ne peut pas être comblé
Je me demande s’il n’existe pas un segment de demande spécifique qui voudrait vraiment une confidentialité vérifiable, même si le coût de calcul était multiplié par 1000. Ce ne serait pas aussi grand que Dropbox, mais j’imagine qu’il y aurait tout de même un certain marché
Je repense à l’époque où tout passait par des cartes d’extension PCIe. Les GPU aussi, et il y avait également des accélérateurs spécialisés comme les coprocesseurs mathématiques. Aujourd’hui, tout est intégré dans du matériel généraliste, moins cher et plus pratique, mais ça ne fera jamais aussi bien que des puces en silicium optimisées pour une fonction précise. C’est pourquoi je plaide pour des cartes dédiées à l’IA/ML plutôt que de tout baser sur des GPU. Les architectures se recoupent en partie, mais une carte IA fondée sur un GPU accepte beaucoup de compromis. Les vrais accélérateurs IA, à mon avis, sont le matériel dédié qui va dans les sockets SXM récents. Mais les sockets SXM ne se trouvent que sur des serveurs et ne sont pas donnés
J’admets l’engouement autour des LLM, mais je me demande vraiment s’il n’existe pas d’autres usages pertinents pour la FHE. Par exemple, on pourrait imaginer héberger côté serveur des algorithmes de trading qui n’ont pas besoin d’être très rapides, en FHE, afin de garantir leur sécurité
Si la FHE est importante, c’est parce qu’aujourd’hui les entreprises peuvent être contraintes, sous la pression des gouvernements, de casser le chiffrement pour certaines cibles. La FHE leur permet de dire en toute bonne foi : « nous ne pouvons jamais voir le texte en clair ». Pour le rôle de transporteur réseau, c’est en partie possible avec l’E2E encryption, etc., mais ce n’est toujours pas possible lorsqu’il faut traiter les données à l’état clair. La protection de la vie privée est, à mon sens, un droit humain fondamental. Le pouvoir de l’État ne devrait s’exercer que de manière très limitée sur les activités démocratiques comme le vote, l’art, la presse ou l’expression
Même si la FHE permettait des calculs arbitraires, la plupart des services existent pour fournir certaines données. Si Google devait garantir la confidentialité de ma requête, il faudrait chiffrer tout l’index de recherche, ce qui est irréaliste. Et d’un point de vue business, je pense qu’en dehors de quelques domaines de très haute confiance et à très haut risque, il n’y a presque aucune incitation à adopter des services fondés sur la FHE
À ma connaissance, il suffit de chiffrer les données sensibles (par exemple mes données de transactions bancaires). La fonction à calculer n’a pas besoin d’être chiffrée ; elle peut être utilisée en combinaison avec des données publiques
Au fond, du point de vue des grandes entreprises, leur source de revenus dépend du fait de pouvoir examiner directement les données ou les requêtes des utilisateurs, donc elles n’ont pas de motivation naturelle à adopter la FHE. Dans la banque ou la finance, ça peut être intéressant, mais ailleurs, on ne sait pas quand ce sera adopté
Sur la question des incitations, je suis d’accord. Mais pas sur la première partie. Les consultations privées sur une base de données en clair existent déjà depuis plusieurs années. En revanche, cela suppose soit un prétraitement assez complexe de la base en clair, soit, dans le pire des cas, un balayage linéaire de toute la base
Je cite spiralwiki.com comme exemple d’implémentation d’un moteur de recherche entièrement privé en FHE, où le serveur ne sait absolument pas quel article Wikipédia l’utilisateur lit spiralwiki.com
« Du point de vue du client », il y aura sans doute des gens prêts à payer pour un service qui protège parfaitement leurs données comme la FHE, mais en pratique ce sera extrêmement cher et le nombre d’abonnés sera minuscule. Si on fait le calcul en partant de l’hypothèse que cela coûte des dizaines de fois plus de calcul qu’aujourd’hui, même un substitut de Google centré sur la vie privée à 100 dollars par an aurait du mal à attirer beaucoup d’abonnés. Et plus le coût augmente, plus le nombre d’abonnés baissera. Il existe des alternatives comme Tor, qui offrent gratuitement une protection assez importante même si elle n’est pas parfaite. Ce n’est pas que le HE soit inutile, c’est juste qu’une toute petite minorité acceptera d’en supporter le coût
L’idée est évoquée qu’Internet pourrait passer d’un modèle où « la surveillance est la norme » à un modèle où « la vie privée est la norme ». Moi aussi, cela fait longtemps que je diffuse des technologies de protection de la vie privée, par exemple en créant des signatures numériques. Mais il faut regarder la réalité : Hacker News ou Facebook détiennent l’identité de tout le monde. Parce que c’est trop facile et rentable. La FHE aussi fait partie de ces « technologies que les gens veulent, mais qui ne se diffusent pas réellement vite ni largement ». À cause de la surcharge opérationnelle et de la complexité, on considère dans la plupart des cas que les solutions existantes fonctionnent déjà suffisamment bien
Quand j’ajoutais des signatures numériques à la fin de mes e-mails, je n’obtenais que des réactions du type « c’est quoi ça ? ». Je me demande si quelqu’un a déjà réussi à convaincre des utilisateurs ordinaires d’adopter le chiffrement côté client
Quand la FHE et l’IA se combinent, l’IA pourrait absorber une partie de la charge de complexité, ce qui en ferait peut-être une combinaison décisive capable d’être réellement adoptée à grande échelle
En pratique, je ne vois pas pourquoi des entreprises adopteraient des solutions de type service FHE qui consomment un million de fois plus de calcul, sont plus difficiles à déboguer et empêchent en plus d’analyser les usages
Commencer la discussion par l’exemple de Google peut prêter à confusion. En général, quand on dit « Google », on pense à la « recherche web », mais la FHE décrite dans le document suppose que toute la donnée d’entrée soit chiffrée avec une seule clé, ce qui colle mal au contexte d’un service de recherche. L’index de recherche de Google fait plusieurs téraoctets, et il me paraît impossible de tout le chiffrer avec une clé donnée. En d’autres termes, la FHE n’est utile que lorsque l’utilisateur contrôle l’ensemble de l’entrée. La référence à Google est trompeuse
Dans des cas comme le CallerID d’Apple, il ne semble pas forcément nécessaire de chiffrer toute la base de données différemment pour chaque utilisateur recherche d’Apple sur le chiffrement homomorphe / recherche privée d’Apple
Un service homomorphe n’a pas besoin de connaître à l’avance la clé de chiffrement. C’est justement l’idée centrale. On présente un exemple de chiffrement très simple où l’on peut additionner des chiffrés sans que la clé soit spécifiée. Si on prend un chiffrement plus puissant et qu’on y ajoute des opérations plus complexes, on peut implémenter des fonctions très variées
Quand on dit Google, on ne pense pas seulement à la recherche, mais aussi à Gmail, Google Docs et à beaucoup d’autres services liés à la vie privée. Ceux qui ne pensent qu’à la recherche n’ont probablement pas lu l’article en question
Je pense qu’il sera difficile de déployer la FHE à court terme dans le calcul généraliste ou les services Internet. Il faudra probablement encore de nombreuses générations de loi de Moore. Mais il existe déjà des domaines où la FHE commence à montrer son intérêt : les smart contracts, la finance et la santé, là où la complexité est plus faible mais où le niveau de sécurité et de confiance requis est très élevé. J’estime que, récemment, grâce à la loi de Moore et à l’optimisation logicielle, la courbe a commencé à se plier vers la praticabilité. Le travail de Zama sur le hardware et les devtools est cité en exemple
Un git en E2EE a déjà été développé. J’ai demandé à son créateur s’il pouvait gérer, côté serveur, des exigences comme les branches protégées ou l’interdiction des force push, mais s’il y a un client malveillant, il n’y avait pas vraiment de réponse. Je me demande si cela évoluera un jour vers un GitHub en E2EE lien Hacker News connexe
Quand j’entends le discours selon lequel la FHE va continuer à gagner en vitesse, cela me rappelle un vieux problème de maths sur la vitesse moyenne. Par exemple : si l’on parcourt une montée d’un mile à 15 mph, à quelle vitesse faut-il descendre le mile suivant pour que la vitesse moyenne sur les 2 miles soit de 30 mph ? Le rythme des progrès passés ne garantit pas les possibilités futures. Ici, il ne s’agit pas d’une limite physique, mais d’une limite algorithmique
Et si la descente était une falaise ? Si l’on prend une vitesse terminale de voiture autour de 200 à 300 mph, on peut même calculer qu’il serait théoriquement possible de parcourir 1 mile en chute libre en 15 secondes. Pour avoir une moyenne de 30 mph sur 2 miles, il faut 4 minutes au total, donc on ajusterait aussi la vitesse en montée en fonction du temps restant, mais en pratique ce serait irréalisable à cause de nombreuses variables
En calculant rigoureusement, il suffit de rouler à 41 mph dans la descente pour obtenir une moyenne de 30 mph sur l’ensemble. Si l’on suppose que l’énoncé implique un arrondi des chiffres ou une marge d’erreur de mesure, on tombe sur ce résultat