j'ai lu l'article, ce qu'a peu pres personne ici n'a fait.
remarques:
le process espion ne doit tourner qu'en mode utilisateur. la technique ne chronomètre pas le temps total donc rajouter un temps aleatoire a la fin ne sert a rien. mettre du code qui ne fait rien dans la branche non prise ne sert a rien. mettre presque le meme code qui prend le meme temps dans la branche non vide ne sert a rien. une seule passe sur le chiffrement est nécessaire.
les gens sont evidemment tres calés sinon ils ne feraient pas de la recherche la dedans.
j'ai pas tout compris a l'article, certains trucs sont vagues.
cependant evidemment tout ceci est futile et infondé car la solution est tres simple.
La personne ici qui a parlé des CMOV a cent fois raison..
(sauf qu'il devait penser à un JMP indirect avec l'adresse remplie par un CMOV, ce qui ne marche sans doute pas car la prédiction de branchement peut maintenant prevoir ça je crois... mais les CMOV peuvent etre utilisés pour remplacer les jumps conditionnels par des séries d'instructions conditionnelles et ça ça marche. )
celle qui a écrit ceci aussi:
"
Ne devrait-on pas dans ce cas repartir de l'algorithme initial non équilibré :
S = M
for i from 1 to n-1 do
S = S * S(mod N)
if di == 1 then
S = S * M(mod N)
et tenter de s'en sortir sans une boucle conditionnelle ?
S = M
for i from 1 to n-1 do
S = S * S(mod N)
S = S * M(mod N) * di + S * not di
Ai-je au moins compris le problème ?
"
oui.
une solution algorithmique comme celle ci marche tres bien et je suis aterré de voir que des tas d'articles hyper sérieux sont publiés depuis des années sur des trucs qui ne marchent absolument pas sans branchements. et on voit "intel fait la sourde oreille etc". je ne peux pas le croire.
en fait le probleme vient du fait que les gens ne connaissent pas l'assembleur.
sinon la solution avec les CMOV aurait été immédiate.
sans connaitre la crypto, quand j'ai vu le DEBUT de l'article sous google avec les termes "prédiction de branchements", j'ai eu l'intuition du probleme et j'ai pensé dans la meme seconde aux CMOV pour le résoudre. je dois avouer que la solution algorithmique est peut etre plus elegante, meme si ça revient globalement au meme. sans CMOV on peut y arriver aussi bien sur, en faisant des contorsions et des masquages sur les bits des registres, bits dont on s'arrange pour que certains proviennent du résultat de la comparaison concernée. ici c'est encore plus simple vu que ces bits sont deja ceux d'un nombre.
en gros quels que soient les deux cal de calculs ça marche. on a qu'a faire le calcul deux fois et stocker les deux puis faire la comparaison et bouger le bon dans le registre de destination.
et en gros n'importe quelle code conditionnel doit pouvoir se ramener a ça d'ailleurs.
c'est assez evident quand on fait de l'assembleur.(enfin moi j'avais deja reflechi par hasard au moyen de virer les Jcc donc ça doit avoir aidé)
je vais chercher vite fait sur le net parce que comme des gens ont deja donné la solution ici, et que c'est assez idiot, c'est obligé que ça se sache... quoique... d'aut papiers depuis plusieurs années font des trucs super compliqués la dessus... comme le truc sur les caches...
alors encore une fois, je suis aterré (et fier) qu'un n00b comme moi voie ça direkt parce qu'aparemment c officiel que y a pas de solution (intel dit qu'on desactivera le BTB si besoin!!!!)
quand on lit ça dans le papier:
"it especially endangers those cryptographic/algorithmic primitives, whose nature is an intrinsic and input-dependant branch process"
# assez de blabla. voila ce que j'en dis.
Posté par helloworld256 . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 4.
j'ai lu l'article, ce qu'a peu pres personne ici n'a fait.
remarques:
le process espion ne doit tourner qu'en mode utilisateur. la technique ne chronomètre pas le temps total donc rajouter un temps aleatoire a la fin ne sert a rien. mettre du code qui ne fait rien dans la branche non prise ne sert a rien. mettre presque le meme code qui prend le meme temps dans la branche non vide ne sert a rien. une seule passe sur le chiffrement est nécessaire.
les gens sont evidemment tres calés sinon ils ne feraient pas de la recherche la dedans.
j'ai pas tout compris a l'article, certains trucs sont vagues.
cependant evidemment tout ceci est futile et infondé car la solution est tres simple.
La personne ici qui a parlé des CMOV a cent fois raison..
(sauf qu'il devait penser à un JMP indirect avec l'adresse remplie par un CMOV, ce qui ne marche sans doute pas car la prédiction de branchement peut maintenant prevoir ça je crois... mais les CMOV peuvent etre utilisés pour remplacer les jumps conditionnels par des séries d'instructions conditionnelles et ça ça marche. )
celle qui a écrit ceci aussi:
"
Ne devrait-on pas dans ce cas repartir de l'algorithme initial non équilibré :
S = M
for i from 1 to n-1 do
S = S * S(mod N)
if di == 1 then
S = S * M(mod N)
et tenter de s'en sortir sans une boucle conditionnelle ?
S = M
for i from 1 to n-1 do
S = S * S(mod N)
S = S * M(mod N) * di + S * not di
Ai-je au moins compris le problème ?
"
oui.
une solution algorithmique comme celle ci marche tres bien et je suis aterré de voir que des tas d'articles hyper sérieux sont publiés depuis des années sur des trucs qui ne marchent absolument pas sans branchements. et on voit "intel fait la sourde oreille etc". je ne peux pas le croire.
en fait le probleme vient du fait que les gens ne connaissent pas l'assembleur.
sinon la solution avec les CMOV aurait été immédiate.
sans connaitre la crypto, quand j'ai vu le DEBUT de l'article sous google avec les termes "prédiction de branchements", j'ai eu l'intuition du probleme et j'ai pensé dans la meme seconde aux CMOV pour le résoudre. je dois avouer que la solution algorithmique est peut etre plus elegante, meme si ça revient globalement au meme. sans CMOV on peut y arriver aussi bien sur, en faisant des contorsions et des masquages sur les bits des registres, bits dont on s'arrange pour que certains proviennent du résultat de la comparaison concernée. ici c'est encore plus simple vu que ces bits sont deja ceux d'un nombre.
en gros quels que soient les deux cal de calculs ça marche. on a qu'a faire le calcul deux fois et stocker les deux puis faire la comparaison et bouger le bon dans le registre de destination.
et en gros n'importe quelle code conditionnel doit pouvoir se ramener a ça d'ailleurs.
c'est assez evident quand on fait de l'assembleur.(enfin moi j'avais deja reflechi par hasard au moyen de virer les Jcc donc ça doit avoir aidé)
je vais chercher vite fait sur le net parce que comme des gens ont deja donné la solution ici, et que c'est assez idiot, c'est obligé que ça se sache... quoique... d'aut papiers depuis plusieurs années font des trucs super compliqués la dessus... comme le truc sur les caches...
alors encore une fois, je suis aterré (et fier) qu'un n00b comme moi voie ça direkt parce qu'aparemment c officiel que y a pas de solution (intel dit qu'on desactivera le BTB si besoin!!!!)
quand on lit ça dans le papier:
"it especially endangers those cryptographic/algorithmic primitives, whose nature is an intrinsic and input-dependant branch process"
...
on sait qu'on a raison.
comments?