AES ou ChaCha20 sur plateformes mobiles

Ma réponse courte : Sur iPhones modernes et appareils Android haut de gamme, je choisis généralement AES-GCM. Sur appareils Android plus anciens, bon marché ou variés, ChaCha20-Poly1305 est souvent un meilleur choix. Pas pour « plus de sécurité », mais pour vitesse, charge CPU, chaleur et batterie.

Si je résume le sujet en une règle simple, c’est celle-ci :

• AES-GCM convient bien quand le matériel AES est présent.
• ChaCha20-Poly1305 est souvent mieux quand AES ne fonctionne qu’en logiciel.
• Les deux ne sont sûrs que si je n’utilise jamais deux fois les mêmes nonces.
• Je traite les données seulement après une vérification réussie.
• Pour les applis mobiles, ce qui compte au final, c’est la classe d’appareil, le stockage local, la transmission, le Keystore/Keychain et TLS 1.3 plus que les débats sur l’algorithme.

Un point ressort : sans matériel AES, l’effort peut coûter jusqu’à 10 fois plus de cycles CPU par octet selon l’article. Sur les appareils Android d’entrée de gamme, ChaCha20 peut être environ 3× plus rapide. On le remarque sur les uploads photo, la synchronisation, les messages et le cache.

Ce à quoi je fais attention :

• iOS / Android haut de gamme : généralement AES-GCM
• Android milieu de gamme / anciens appareils : souvent ChaCha20-Poly1305
• Données locales : choix selon la classe d’appareil
• Données API et messages : gestion propre des clés et nonces
• Pour tous les cas : Android Keystore, Apple Keychain, nonce 96 bits par opération, TLS 1.3, rotation régulière des clés

En résumé : Si je développe une appli pour plusieurs classes Android, je veux une performance homogène. Si je cible des appareils récents avec matériel AES, AES-GCM est souvent mon premier choix.

The Modern Cipher Showdown : plongée approfondie dans ChaCha20-Poly1305 vs. AES-GCM

sbb-itb-1cfd233

Comparaison rapide

Je résume l’article ainsi : La question centrale n’est pas « Quel algorithme est meilleur ? », mais « Sur quel appareil tourne mon app, et où sont les données ? »

AES-GCM vs. ChaCha20-Poly1305 : Comment les deux procédés diffèrent dans les apps mobiles

Au final, il s’agit de trois choses : Structure, Utilisation du hardware et Erreurs d’implémentation. Pour les apps mobiles, ce qui compte au quotidien, c’est surtout le hardware disponible, le temps d’exécution en logiciel et la question de ce qui se passe si l’implémentation déraille.

AES-GCM sur Android et iOS

AES-GCM est un procédé AEAD basé sur AES. Sur les appareils avec accélération hardware, il est très rapide. Sans ce support, les performances chutent souvent nettement.

ChaCha20-Poly1305 sur Android et iOS

ChaCha20-Poly1305 est un procédé AEAD basé sur ChaCha20. Il est conçu pour s’exécuter en logiciel et est donc souvent avantageux sur les appareils Android plus anciens ou bon marché.

Exigences de sécurité partagées par les deux procédés

Les deux procédés ont le même point sensible : Une nonce ne doit jamais être réutilisée avec la même clé. Si cela arrive, la sécurité des deux procédés est compromise. Avec AES-GCM, des falsifications peuvent même devenir possibles.

Tout aussi important : Les données déchiffrées ne doivent être traitées qu’après authentification réussie. En d’autres termes : vérifier avant de toucher. Sinon, c’est comme si on fermait la porte d’entrée après être entré.

Comment cela impacte la vitesse et la batterie est montré dans la section suivante.

Vitesse et batterie : pourquoi la classe d’appareil fait la différence

Sur les appareils mobiles, c’est surtout la catégorie d’appareil qui fait la différence. AES-GCM profite beaucoup de l’accélération matérielle, tandis que ChaCha20-Poly1305 reste rapide même quand tout tourne en logiciel. C’est là que se voit l’écart entre le haut de gamme, le milieu de gamme et les appareils plus anciens.

Pour les applis avec photos, messages et mises à jour d’enchères, un point compte avant tout : Comment fonctionnent la synchronisation et le chiffrement sur les smartphones plus anciens ? Car c’est là qu’on ressent le plus les retards, la charge CPU élevée et la batterie qui se vide vite.

iPhones modernes et flagships Android

Sur les iPhones récents et les appareils Android haut de gamme, AES-GCM est généralement plus rapide. La raison est simple : le matériel prend en charge directement les opérations AES et atteint des débits très élevés. En même temps, la charge CPU, la chauffe et la consommation de batterie restent faibles. Cela rend aussi les performances plus prévisibles sur différents appareils Android.

Milieu de gamme, appareils plus anciens et d’entrée de gamme Android

Beaucoup d’appareils Android plus anciens ou bon marché sans extensions cryptographiques ARMv8 doivent exécuter AES entièrement en logiciel. Cela coûte nettement plus de temps de calcul : AES en logiciel peut consommer jusqu’à 10 fois plus de cycles CPU par octet que l’AES accéléré matériellement. L’appareil chauffe alors plus vite et la batterie se vide nettement plus rapidement.

ChaCha20-Poly1305 est conçu pour être exécuté en logiciel et est souvent clairement devant ici. On le remarque directement lors des synchronisations, des uploads de photos et des données locales chiffrées.

Le tableau montre à quel point la catégorie d’appareil peut influencer la vitesse et la batterie.

Toutes les données dépendent du benchmark et varient selon le SoC et l’implémentation des bibliothèques.

Bien réaliser les benchmarks

Une seule valeur de vitesse sur un appareil récent ne sert pas à grand-chose en pratique. Il est plus utile de tester spécifiquement sur des appareils plus anciens encore utilisés activement.

Mesure pendant 5 à 10 minutes sous charge :

• Débit
• Latence
• Énergie par octet

Important aussi : utilise sur les deux plateformes la même bibliothèque. Sinon tu ne compares pas les algorithmes, mais juste des différences d’implémentation.

Le paragraphe suivant montre à quel point cela se remarque sur les données locales, les images et les appels API.

Stockage hors ligne et transfert de données dans les applis de marketplace

Pour Gunfinder, un point est crucial : Les données sont-elles stockées localement ou transférées ? C’est précisément là que réside le risque et ce qui détermine la mesure de protection la plus efficace.

Stockage hors ligne : bases de données, cache, brouillons et données de compte et de profil

Les données stockées localement sont souvent sous-estimées. Pourtant, c’est là que se trouve une partie du problème. Les résultats de recherche enregistrés, le contenu du panier ainsi que les données de compte et de profil se trouvent directement sur l’appareil. Si une sauvegarde n’est pas protégée ou si l’appareil est compromis, ces données peuvent devenir accessibles.

Pour les données locales, l’appareil cible est primordial. Si l’appareil dispose d’une accélération AES, AES-GCM est un choix solide. En l’absence de ce support, ChaCha20-Poly1305 est souvent plus efficace. La clé doit être stockée en toute sécurité dans le Android Keystore ou dans le Apple Keychain ou Secure Enclave. Et un point est non négociable : chaque fichier doit avoir un nonce unique de 96 bits. Réutiliser un nonce compromet la sécurité et l’intégrité.

Le même principe de base s’applique aussi aux transmissions. Là, l’accent est mis ailleurs : sur les données utiles et la journalisation.

Transmission des données : appels API, uploads d’images, messages et mises à jour d’enchères

TLS protège le transport. Cela ne signifie pas automatiquement que les données utiles elles-mêmes sont protégées. Si des messages privés entre acheteurs et vendeurs ou des données d’enchères se retrouvent dans les logs serveur, ils sont lisibles en clair sans chiffrement supplémentaire au niveau de l’application. C’est là qu’interviennent AES-GCM et ChaCha20-Poly1305. Ils complètent le chiffrement du transport comme seconde couche de protection.

Le point crucial n’est donc pas principalement l’algorithme. Ce qui compte, c’est si les données résident sur l’appareil ou transitent par le réseau.

Ce qui compte plus que le choix du cipher

Pour les données locales, la classe de l’appareil est le point principal. Pour les données API, uploads et messages, la gestion propre des clés et des nonces est essentielle.

Pour Gunfinder, ce qui compte au final, c’est précisément : une gestion propre des clés et des nonces. La variante la mieux adaptée au quotidien est présentée dans la section suivante.

Aide à la décision et conclusion pour les apps Gunfinder

Pour Gunfinder, une chose est primordiale : quel appareil utilise l’app et quelles données sont traitées ? C’est précisément de là que découle en pratique le choix de la méthode. Le tableau ci-dessous résume cela et classe les workflows typiques de Gunfinder.

Pour tous les cas, la même structure de base s'applique : un stockage sécurisé des clés via Android Keystore ou Apple Keychain, des nonces uniques par opération, TLS 1.3 pour chaque transmission et une rotation régulière des clés. Sans ces points, même le meilleur algorithme n’aide que partiellement.

Quand AES-GCM est le meilleur choix

AES-GCM convient bien aux iPhones modernes et aux appareils Android haut de gamme, lorsque le matériel AES est présent et que le backend s’appuie déjà dessus. La méthode montre alors ses forces là où les appareils le supportent directement.

Quand ChaCha20-Poly1305 est le meilleur choix

Dès que des appareils Android plus anciens ou moins chers entrent en jeu, ChaCha20-Poly1305 est souvent le choix le plus fiable. La raison est simple : les performances restent généralement plus constantes sur ces appareils que celles de l’AES logiciel.

Les points clés

Les deux algorithmes sont sûrs lorsqu’ils sont utilisés correctement. En résumé : AES-GCM convient bien aux environnements axés sur le matériel, ChaCha20-Poly1305 plutôt aux flottes Android mixtes.

FAQs

Comment savoir si mon appareil cible dispose de matériel AES ?

La présence d’un accélérateur matériel AES sur ton appareil dépend du processeur intégré. Beaucoup de processeurs récents supportent AES-NI. Cela rend le chiffrement nettement plus efficace.

Sur les appareils Android et iOS, le mieux est de vérifier les spécifications techniques du processeur. Sur les smartphones et tablettes basés sur ARM, l’accélération matérielle pour les opérations cryptographiques est souvent intégrée. Le système d’exploitation l’utilise généralement automatiquement.

Que se passe-t-il en cas de réutilisation d’une nonce ?

Si tu utilises une nonce plus d’une fois, tu compromets la sécurité du chiffrement.

Les attaquants peuvent alors détecter des motifs dans les données chiffrées ou même déduire la clé utilisée.

Cela affecte gravement la confidentialité de tes données. C’est pourquoi la nonce doit être toujours nouvelle et unique à chaque opération de chiffrement.

TLS 1.3 suffit-il sans chiffrement supplémentaire dans l’app ?

Non. TLS 1.3 protège les données pendant la transmission. Il ne couvre pas les données stockées localement dans l’appareil.

Si tu veux protéger les données de bout en bout, tu as donc besoin en plus d’un chiffrement local. Pour les transactions sensibles, AES-256 peut aussi être pertinent.

Ce n’est que la combinaison d’une transmission sécurisée et d’un chiffrement local qui protège efficacement, même en cas de problèmes techniques ou d’accès non autorisé à l’appareil final.

Articles de blog connexes

• Vue d'ensemble : standards de cryptage dans le e-commerce
• Comment les audits améliorent la sécurité du cryptage
• Fiabilité des systèmes biométriques : ce que les chasseurs doivent savoir
• Technologies de cryptage : aperçu de la sécurité et des performances