http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
Le pb ne vient pas de l'algo !
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
The AES designers and official evaluators
* considered timing attacks in detail,
* claimed that table lookup was ``not vulnerable to timing attacks,''
* claimed that Rijndael gained a ``major speed advantage over its
competitors'' for software protected against timing attacks,
* made the same comment in its summaries of the finalists, and
* made the same comment in its paragraph explaining the selection of
Rijndael.
The problem is that, when they stated ``Table lookup: not vulnerable to
timing attacks,'' they were simply wrong. Table lookup _is_ vulnerable
to timing attacks.
Le pb ne vient pas de l'algo !
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
The AES designers and official evaluators
* considered timing attacks in detail,
* claimed that table lookup was ``not vulnerable to timing attacks,''
* claimed that Rijndael gained a ``major speed advantage over its
competitors'' for software protected against timing attacks,
* made the same comment in its summaries of the finalists, and
* made the same comment in its paragraph explaining the selection of
Rijndael.
The problem is that, when they stated ``Table lookup: not vulnerable to
timing attacks,'' they were simply wrong. Table lookup _is_ vulnerable
to timing attacks.
Le pb ne vient pas de l'algo !
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
The AES designers and official evaluators
* considered timing attacks in detail,
* claimed that table lookup was ``not vulnerable to timing attacks,''
* claimed that Rijndael gained a ``major speed advantage over its
competitors'' for software protected against timing attacks,
* made the same comment in its summaries of the finalists, and
* made the same comment in its paragraph explaining the selection of
Rijndael.
The problem is that, when they stated ``Table lookup: not vulnerable to
timing attacks,'' they were simply wrong. Table lookup _is_ vulnerable
to timing attacks.
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
Ce cheval de troie "serait" capable de mesurer les différentes phases du
cryptage --> donc le pgm crypteur est compilé avec les infos de
déboggages, et le cheval de troie à accès à un debogger/profileur -->
autant dire que meme avec un algo a temps constant ce cheval de troie
pourrait avoir accès à toutes les données présentes sur le PC donc à la
clé sans même trop se casser la tete (lecture du clavier, lecture des
ports usb, ...)
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
Ce cheval de troie "serait" capable de mesurer les différentes phases du
cryptage --> donc le pgm crypteur est compilé avec les infos de
déboggages, et le cheval de troie à accès à un debogger/profileur -->
autant dire que meme avec un algo a temps constant ce cheval de troie
pourrait avoir accès à toutes les données présentes sur le PC donc à la
clé sans même trop se casser la tete (lecture du clavier, lecture des
ports usb, ...)
cela signifie qu'il y a un cheval de troie sur le pc qui crypte.
Ce cheval de troie "serait" capable de mesurer les différentes phases du
cryptage --> donc le pgm crypteur est compilé avec les infos de
déboggages, et le cheval de troie à accès à un debogger/profileur -->
autant dire que meme avec un algo a temps constant ce cheval de troie
pourrait avoir accès à toutes les données présentes sur le PC donc à la
clé sans même trop se casser la tete (lecture du clavier, lecture des
ports usb, ...)
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
Ce n'est pas aussi simple. L'article vaut en tout cas la peine d'être lu
(ce que je viens de faire) et étudié (ce que je n'ai pas encore fait).
Bonjour,
On Thu, 21 Apr 2005 wrote:http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
Comme pour n'importe quel autre algo. Les timing attacks, ça marche à peu
près partout.
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
Et contrairement à ce qu'affirme Thierry Nivon, il n'y a pas de binaire
étranger tournant sur le serveur. C'est réellement une attaque entre un
serveur possédant et mettant en oeuvre une clé et un client mesurant le
temps mis pour effectuer les opérations de chiffrement.- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
La conclusion n'est pas aussi franche. Bernstein propose des pistes, tant
pour les implémenteurs d'AES que pour les fondeurs de microprocesseurs. Le
plus gros du travail en revient aux fondeurs,
implémentation d'AES fonctionnant en temps constant (avec des opérations
logiques, et sans lookup) rendrait cette implémentation beaucoup trop
lente.
A part ça, l'article mérite en effet d'être lu, et ceux qui ont lu la
première version (20041111 je crois, je l'ai effacé) trouveront des
ajouts intéressants, sur d'autres causes menant à ces problèmes de cache
timing. On voit clairement que la complexité des microprocesseurs actuels
est difficilement maîtrisable à la main.
Bonjour,
On Thu, 21 Apr 2005 cgonzale@numericable.fr wrote:
http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
Comme pour n'importe quel autre algo. Les timing attacks, ça marche à peu
près partout.
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
Et contrairement à ce qu'affirme Thierry Nivon, il n'y a pas de binaire
étranger tournant sur le serveur. C'est réellement une attaque entre un
serveur possédant et mettant en oeuvre une clé et un client mesurant le
temps mis pour effectuer les opérations de chiffrement.
- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
La conclusion n'est pas aussi franche. Bernstein propose des pistes, tant
pour les implémenteurs d'AES que pour les fondeurs de microprocesseurs. Le
plus gros du travail en revient aux fondeurs,
implémentation d'AES fonctionnant en temps constant (avec des opérations
logiques, et sans lookup) rendrait cette implémentation beaucoup trop
lente.
A part ça, l'article mérite en effet d'être lu, et ceux qui ont lu la
première version (20041111 je crois, je l'ai effacé) trouveront des
ajouts intéressants, sur d'autres causes menant à ces problèmes de cache
timing. On voit clairement que la complexité des microprocesseurs actuels
est difficilement maîtrisable à la main.
Bonjour,
On Thu, 21 Apr 2005 wrote:http://cr.yp.to/papers.html#cachetiming
En résumé:
- la variabilité des temps d'accès mémoire aux S-boxes et leur
dépendance aux données en entrée sont une grave menace pour la
sécurité de AES
Comme pour n'importe quel autre algo. Les timing attacks, ça marche à peu
près partout.
- cette attaque montre que sous certaines conditions et avec
relativement peu de texte clair disponible on peut DEVINER une clé AES
rien qu'en mesurant le nombre de cycles d'horloge pour chiffrer un bloc
Et contrairement à ce qu'affirme Thierry Nivon, il n'y a pas de binaire
étranger tournant sur le serveur. C'est réellement une attaque entre un
serveur possédant et mettant en oeuvre une clé et un client mesurant le
temps mis pour effectuer les opérations de chiffrement.- il semble extremement difficile de coder une implémentation de AES
en temps constant
- l'auteur de l'article plaide pour l'utilisation d'algo
implémentables en temps constant (donc n'utilisant par ex. que des
opérations logiques et des rotations avec nombre de décalage fixe)
La conclusion n'est pas aussi franche. Bernstein propose des pistes, tant
pour les implémenteurs d'AES que pour les fondeurs de microprocesseurs. Le
plus gros du travail en revient aux fondeurs,
implémentation d'AES fonctionnant en temps constant (avec des opérations
logiques, et sans lookup) rendrait cette implémentation beaucoup trop
lente.
A part ça, l'article mérite en effet d'être lu, et ceux qui ont lu la
première version (20041111 je crois, je l'ai effacé) trouveront des
ajouts intéressants, sur d'autres causes menant à ces problèmes de cache
timing. On voit clairement que la complexité des microprocesseurs actuels
est difficilement maîtrisable à la main.