Chapitre IV
ETUDE DE L'EXISTANT
Dans ce chapitre, nous présentons les différents
travaux existants sur la comparaison des bibliothèques FHE en se
limitant surceux en rapport de notre étude.
1 L'étude de Safouane E. BENELKADI [11]
fait une évaluation comparative des performances
de Microsoft SEAL et HELib dans le contexte de multiplication
matricielle avec chiffrement
homomorphe, incluant une analyse d'algorithmes classiques et
hybrides.
Contexte de l'étude
-- Évaluation des bibliothèques:
-- Microsoft SEAL (Simple Encrypted Arithmetic
Library)
-- HELib (Homomorphic Encryption Library)
-- Algorithmes testés:
-- Approche classique « naïve »
-- Algorithme de Strassen optimisé
-- Algorithme hybride adaptatif
Méthodologie expérimentale
Configuration des tests
-- Matrices carrées A de dimension k =
2n
-- Opération : A X A avec
implémentations:
-- Version non chiffrée
-- Versions chiffrées (SEAL/HELib)
Algorithme hybride
-- Logique adaptative seuillée :
|
Méthode =
|
?????Strassen
si k> kseuil
???? Naïve sinon
|
-- Optimisation de complexité : O(n3)
? O(n2.81) Résultats
comparatifs
Performances de SEAL contre HELib
-- Avantages SEAL:
-- Temps d'exécution réduit de 35-40% contre HELib
-- Gestion optimisée du bruit cryptographique
CHAPITRE 4. ETUDE DE L'EXISTANT 44
Mémoire de Master 2 Recherche 44 MOUYOUME
DIEUDONNE(c) UYI
-- Limitations SEAL:
-- Absence de système d'alerte pour le bruit
résiduel
-- Nécessité de calibration manuelle
Analyse des limitations
Contraintes cryptographiques
-- Phénomène de « mort par bruit »
-- Facteurs d'atténuation:
-- Sélection de circuits de calcul courts
-- Bootstrapping cryptographique
Conclusion
Cette étude montre que dans le contexte des
opérations matricielles, Microsoft SEAL démontre une
supériorité temporelle par rapport à HELib, notamment pour
la multiplication de matrices. Cette performance s'explique par une gestion
optimisée du bruit cryptographique: SEAL permet des seuils de
tolérance plus élevés avant que le bruit ne compromette
les calculs. Cependant, cette bibliothèque présente une lacune
opérationnelle majeure: elle n'alerte pas l'utilisateur lors
d'échecs de déchiffrement causés par l'accumulation de
bruit, imposant ainsi un contrôle manuel rigoureux des paramètres
de sécurité.
2 Dans leur étude, Carlos Aguilar
Melchor, Marc Olivier Kilijian, Cédric Lefebvre, and Thomas Ricosset [3]
explorent l'utilisation de modules de texte clair (plaintext moduli) de grande
taille avec trois bibliothèques FHE (SEAL, HElib-MP et FV-NFLlib) pour
comparer leurs fonctionnalités et efficacité. Une adaptation
spécifique a été nécessaire pour HElib,
modifiée en HElib-MP afin de prendre en charge les modules
multi-précision , tandis que les versions standard de SEAL (v2.3 pour
des modules = 60 bits et v2.1 pour des modules supérieurs) et FV-NFLlib
ont été utilisées sans modifications.
Bien qu'une approche basée sur le
théorème des restes chinois permettrait des calculs
multi-précision génériques, elle se révèle
inadaptée aux cas nécessitant des modules spécifiques (ex.
ECDSA/RSA), non factorisables de manière optimale.
Leur analyse compare les stratégies employées
par ces bibliothèques pour gister le bruit cryptographique et les
conversions de représentation, en mesurant leur impact sur les
performances globales.
Paramètres expérimentaux:
Matériel : Un coeur d'un processeur
Intel Xeon E5-2695 v3 (2,30 GHz). Sécurité : Configuration SHE
garantissant= 128 bits via le script Albrecht-Player-Scott, aligné sur
les standards de SEAL v2.3.
Extrapolation : Un doublement des exigences
de sécurité n'augmenterait les coûts que
linéairement, validant la généralisation de nos
résultats à des niveaux de sécurité plus
élevés. Cette méthodologie souligne les compromis entre
flexibilité des modules, efficacité computa-
CHAPITRE 4. ETUDE DE L'EXISTANT 45
tionnelle et contraintes cryptographiques dans les
implémentations FHE modernes. Principales conclusions de
l'analyse de performance
1. Critères de sélection des
bibliothèques
-- Pour logp = 1 :
-- SEAL v2.3 optimal jusqu'à une profondeur de calcul
-12
-- Performance équivalente entre SEAL v2.3 et HElib
(12-25)
-- Supériorité nette d'HElib au-delà de
25
-- Pour logp = 60 :
-- FV-NFLlib/SEAL v2.3 > HElib (jusqu'à -40)
-- Recommandation: SEAL v2.3 (développement actif +
ergonomie)
-- Pour logp > 60 :
-- Cas 1 : Module factorisable (sous-modules 60 bits) -
Approche CRT + SEAL v2.3
-- Cas 2 : Module premier/critptographique - FV-NFLlib
(log q < 2000) ou HElib-MP
(log q > 2000)
2. Observations théoriques
-- Représentations non-CRT : Peu
compétitives même avec Karatsuba
-- Comparaison BGV/FV :
-- Supériorité de BGV pour grands modules
-- Piste d'optimisation: Implémentation simplifiée
basée sur NFLlib
-- Synergies technologiques:
-- Combinaison prometteuse : NFLlib + Approche FullRNS (Bajard
et al.)
-- Potentiel d'amélioration -30% selon tests
préliminaires
Recommandations stratégiques
-- Adapter l'architecture aux contraintes:
-- Profondeur < 25 : Privilégier HElib
-- Modules < 60 bits : SEAL v2.3
-- Modules critiques : Combinaison FV-NFLlib/HElib-MP
3 La recherche de Faneela 1 et al.[4] évalue les
performances de deux bibliothèques de chiffrement entièrement
homomorphe (FHE), SEAL (développée par Microsoft) et OpenFHE, en
se focalisant sur les schémas BGV (optimisé pour les calculs
exacts) et CKKS (spécialisé dans l'arithmétique
approximative). L'objectif principal est de mesurer leurs surcoûts
computation-nels, leur évolutivité et leur efficacité dans
des environnements multi-plateformes (Windows et Linux). Les
expériences, menées sur un ordinateur portable
équipé d'un processeur Intel Core i7-8550U, de 16 Go de RAM et
d'un SSD de 512 Go, ont comparé systématiquement le temps
d'exécution et l'utilisation de la mémoire. Des paramètres
cryptographiques clés - tels que le degré de polymodule, le
module de coefficients et le facteur d'échelle - ont été
ajustés dynamiquement pour refléter des scénarios
opérationnels réalistes, notamment pour les multiplications
homomorphes, dont la complexité nécessite des configurations
adaptatives.
Résultats et observations
Mémoire de Master 2 Recherche 45 MOUYOUME DIEUDONNE(c)
UYI
CHAPITRE 4. ETUDE DE L'EXISTANT 46
Mémoire de Master 2 Recherche 46 MOUYOUME
DIEUDONNE(c) UYI
Les résultats démontrent une
supériorité nette d'OpenFHE sur SEAL dans toutes les
configurations testées. Par exemple, pour des multiplications à
haute profondeur (degré de polymo-dule = 14), OpenFHE réduit le
temps d'exécution de 20 à 35% grâce à une
optimisation des opérations vectorielles et une gestion plus efficace du
parallélisme. Par ailleurs, Linux s'est imposé comme la
plateforme la plus performante, notamment pour la gestion de la mémoire
cache et l'exploitation des coeurs CPU, surpassant Windows dans tous les cas de
figure. Concernant les schémas, BGV a montré une stabilité
remarquable pour les calculs exacts à grande échelle, tandis que
CKKS, bien que flexible, exige des ajustements fréquents du facteur
d'échelle pour maintenir la précision des résultats, ce
qui complexifie son déploiement dans des applications temps
réel.
Implications et perspectives
Ces conclusions soulignent l'importance critique du choix
combiné de la bibliothèque, du schéma FHE et du
système d'exploitation pour les applications sensibles à la
latence. Les performances d'OpenFHE suggèrent son adoption
privilégiée dans les architectures modernes, notamment pour les
systèmes cloud ou les calculs distribués. Toutefois, des
défis persistent, comme l'optimisation des paramètres
cryptographiques pour CKKS ou l'intégration de bootstrapping
(rechargement des chiffrés) dans des workflows complexes.
| 
