Adiantum : Google dit avoir une solution pour le chiffrement des appareils Android d’entrée de gamme
Le 08 février 2019 à 09h39
2 min
Société numérique
Société
Ces derniers ne peuvent bénéficier de l'accélération d'AES via leurs SoC à bas coût. En attendant que cette technologie se démocratise, le géant américain a planché sur une solution logicielle.
Elle se base sur la même technique utilisée pour le chiffrement des connexions HTTPS dans des conditions identiques et mise sur ChaCha. Mais le duo ChaCha20-Poly1305 ne peut être utilisé de manière classique sur un système de fichiers, car peu adapté à cet usage (voir les détails).
C'est ici qu'Adiantum se distingue : il permet d'obtenir un bloc de 4 096 octets chiffrés depuis un bloc de 4 096 octets en clair. Il se repose en partie sur Poly1305 pour la phase de hash, et sur ChaCha12 (12 tours de calculs plutôt que 20) pour le chiffrement.
Selon Google, ce choix n'impacte pas la sécurité puisqu'actuellement, huit tours suffisent à s'assurer que les données ne sont pas compromises. AES reste en partie utilisé, mais pour une part mineure des données (16 octets).
L'ensemble est annoncé comme cinq fois plus efficace qu'un chiffrement AES-256-XTS sans accélération matérielle, mais reste moins performant si une telle fonctionnalité est présente. Adiantium ne doit donc être utilisé que sur des appareils où elle fait défaut.
Un document plus technique vient détailler la solution. Google précise que les constructeurs peuvent activer Adiantum, qui devrait se généraliser avec l'arrivée d'Android Q. La société précise d'ailleurs qu'elle souhaite faire du chiffrement une obligation sur tous les appareils à l'avenir.
À voir si cette initiative en inspire d'autres, notamment dans le domaine de la sécurité des objets connectés, où le chiffrement n'est malheureusement pas toujours considéré comme une obligation, là aussi pour des raisons de performances.
Le 08 février 2019 à 09h39
Commentaires (9)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 08/02/2019 à 14h33
On an ARM Cortex-A7 processor, Adiantum decrypts 4096-byte messages at 10.6 cycles per byte, over five times faster than AES-256-XTS, with a constant-time implementation.
Donc dans les 50 cycles/octet sur du ARM ?
Sur du Intel, AES-256-XTS, sans instructions AES-NI, sans SIMD, et sur du mono-thread, c’est environ 20 cycles/octet (pour mon application codée en C et tournant sur un i7-2600k, j’en suis à 21, XTS inclus).
Le 08/02/2019 à 14h49
Est-ce vraiment une bonne idée de multiplier les “standards” de chiffrement ?
Je crois que je préférerais avoir le classique XTS-AES sur de l’entrée de gamme - même si c’est plus lent - , plutot que d’avoir un machin spécifique made-in-google qui disparaitra d’ici quelques mois quand l’accélération AES sera dispo sur tous les SoC.
Le 08/02/2019 à 16h02
déjà qu’un entrée de gamme c’est lent, avec un algo 5 fois plus lent ça risque d’être inutilisable.
" />
mais bon j’imagine que les gars de chez Google ne savent pas ce qu’ils font, et ont dépensé du temps et de l’argent stupidement alors qu’il suffit d’attendre encore quelques mois.
Le 09/02/2019 à 12h32
Le 12/02/2019 à 15h21
byte = octet
bit = bit
Donc 10.6 cycles/byte ==> 10.6 cycles/octet
Le 12/02/2019 à 15h24
Sans oublier que là on parle de SoC d’entrée de gamme, avec de faibles puissance de calcul, donc la comparaison avec un processeur desktop n’a absolument aucun intérêt.
Le 12/02/2019 à 16h39
Le 12/02/2019 à 17h07
Ok j’avais mal compris ton message, je croyais que “Donc dans les 50 cycles/octet sur du ARM” s’appliquait à Adantium et je ne comprenais pas.
Par contre, non, même avec du mono-thread, ça ne fait aucun sens de comparer les perf d’un SoC ARM avec un processeur desktop intel. Les architecture n’ont rien à voir (RISC vs. CISC, jeux d’instruction incomparables ,…).
Le 13/02/2019 à 12h27