Je viens de lire un article ou l'on parle d'avoir trouv=E9 une cl=E9s
priv=E9 par le biais d'un algorithme, y aurait il d'autre solution que
la force brute ?
http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
A. Caspis
ptilou wrote:
Je viens de lire un article ou l'on parle d'avoir trouvé une clés privé par le biais d'un algorithme, y aurait il d'autre solution que la force brute ? http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Une maladresse dans l'implémentation de ECDSA. C'est expliqué ici: http://www.youtube.com/watch?vêg0VyRTld8#t30s
AC
ptilou wrote:
Je viens de lire un article ou l'on parle d'avoir trouvé une clés
privé par le biais d'un algorithme, y aurait il d'autre solution que
la force brute ?
http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Une maladresse dans l'implémentation de ECDSA. C'est expliqué ici:
http://www.youtube.com/watch?vêg0VyRTld8#t30s
Je viens de lire un article ou l'on parle d'avoir trouvé une clés privé par le biais d'un algorithme, y aurait il d'autre solution que la force brute ? http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Une maladresse dans l'implémentation de ECDSA. C'est expliqué ici: http://www.youtube.com/watch?vêg0VyRTld8#t30s
AC
Jean-Marc Desperrier
ptilou wrote:
Je viens de lire un article ou l'on parle d'avoir trouvé une clés privé par le biais d'un algorithme, y aurait il d'autre solution que la force brute ? http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Pas n'importe quelle privée, une clé privée de courbe elliptique, ce qui signifie que l'algorithme crypto sous-jacent est DSA.
Et DSA a un point faible, il utilise un générateur aléatoire, qui doit être *parfaitement* sûr, sinon la clé privée peut être retrouvée. C'est décrit brièvement ici : http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity
Il y a une description plus détaillée du problème ici, qui aborde le cas PS3 : http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/
Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par François Grieu, et Thomas Pornin est en train d'y proposer une solution astucieuse au problème : C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un hachage initialisée avec la clé privée et le contenu du message. - La fonction de hash ne permet pas de revenir au données de départ sinon l'algo est très fortement cassé (beaucoup plus que MD5 ne l'est aujourd'hui), donc on ne révèle rien sur la clé privée en faisant cela. - Comme la clé privée est totalement inconnue de l'attaquant (sinon de toute façon, c'est déjà cassé), le résultat du hashage est absolument imprévisible pour lui, et indistinguable d'une valeur aléatoire (encore une propriété que toute fonction de hachage un tant soit peu raisonnable vérifie très bien, y compris MD5 d'ailleurs).
Il faut éviter de se précipiter et laisser mûrir l'idée, afin d'avoir le temps de vérifier qu'il n'y a pas un piège caché. Cependant la logique qui montre que ça devrait être solide n'est pas très compliquée, donc ça semble assez robuste.
Le problème c'est que les gens suffisamment mal informés pour ne pas utiliser DSA proprement, avec un vrai générateur aléatoire, ne le seront jamais assez pour utiliser cette alternative à la place. L'avantage serait surtout sur une plate-forme où l'on doute d'avoir un générateur aléatoire sérieux disponible, et on pourra éviter complétement de se poser la question en faisant cela. A condition que cet algo soit bien validé comme étant vraiment sûr.
ptilou wrote:
Je viens de lire un article ou l'on parle d'avoir trouvé une clés
privé par le biais d'un algorithme, y aurait il d'autre solution que
la force brute ?
http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Pas n'importe quelle privée, une clé privée de courbe elliptique, ce qui
signifie que l'algorithme crypto sous-jacent est DSA.
Et DSA a un point faible, il utilise un générateur aléatoire, qui doit
être *parfaitement* sûr, sinon la clé privée peut être retrouvée.
C'est décrit brièvement ici :
http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity
Il y a une description plus détaillée du problème ici, qui aborde le cas
PS3 :
http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/
Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par
François Grieu, et Thomas Pornin est en train d'y proposer une solution
astucieuse au problème :
C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un
hachage initialisée avec la clé privée et le contenu du message.
- La fonction de hash ne permet pas de revenir au données de départ
sinon l'algo est très fortement cassé (beaucoup plus que MD5 ne l'est
aujourd'hui), donc on ne révèle rien sur la clé privée en faisant cela.
- Comme la clé privée est totalement inconnue de l'attaquant (sinon de
toute façon, c'est déjà cassé), le résultat du hashage est absolument
imprévisible pour lui, et indistinguable d'une valeur aléatoire (encore
une propriété que toute fonction de hachage un tant soit peu raisonnable
vérifie très bien, y compris MD5 d'ailleurs).
Il faut éviter de se précipiter et laisser mûrir l'idée, afin d'avoir le
temps de vérifier qu'il n'y a pas un piège caché. Cependant la logique
qui montre que ça devrait être solide n'est pas très compliquée, donc ça
semble assez robuste.
Le problème c'est que les gens suffisamment mal informés pour ne pas
utiliser DSA proprement, avec un vrai générateur aléatoire, ne le seront
jamais assez pour utiliser cette alternative à la place. L'avantage
serait surtout sur une plate-forme où l'on doute d'avoir un générateur
aléatoire sérieux disponible, et on pourra éviter complétement de se
poser la question en faisant cela. A condition que cet algo soit bien
validé comme étant vraiment sûr.
Je viens de lire un article ou l'on parle d'avoir trouvé une clés privé par le biais d'un algorithme, y aurait il d'autre solution que la force brute ? http://www.gamepro.fr/2010/12/31/playstation/la-ps3-vraiment-hackee/510049/
Pas n'importe quelle privée, une clé privée de courbe elliptique, ce qui signifie que l'algorithme crypto sous-jacent est DSA.
Et DSA a un point faible, il utilise un générateur aléatoire, qui doit être *parfaitement* sûr, sinon la clé privée peut être retrouvée. C'est décrit brièvement ici : http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Sensitivity
Il y a une description plus détaillée du problème ici, qui aborde le cas PS3 : http://rdist.root.org/2010/11/19/dsa-requirements-for-random-k-value/
Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par François Grieu, et Thomas Pornin est en train d'y proposer une solution astucieuse au problème : C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un hachage initialisée avec la clé privée et le contenu du message. - La fonction de hash ne permet pas de revenir au données de départ sinon l'algo est très fortement cassé (beaucoup plus que MD5 ne l'est aujourd'hui), donc on ne révèle rien sur la clé privée en faisant cela. - Comme la clé privée est totalement inconnue de l'attaquant (sinon de toute façon, c'est déjà cassé), le résultat du hashage est absolument imprévisible pour lui, et indistinguable d'une valeur aléatoire (encore une propriété que toute fonction de hachage un tant soit peu raisonnable vérifie très bien, y compris MD5 d'ailleurs).
Il faut éviter de se précipiter et laisser mûrir l'idée, afin d'avoir le temps de vérifier qu'il n'y a pas un piège caché. Cependant la logique qui montre que ça devrait être solide n'est pas très compliquée, donc ça semble assez robuste.
Le problème c'est que les gens suffisamment mal informés pour ne pas utiliser DSA proprement, avec un vrai générateur aléatoire, ne le seront jamais assez pour utiliser cette alternative à la place. L'avantage serait surtout sur une plate-forme où l'on doute d'avoir un générateur aléatoire sérieux disponible, et on pourra éviter complétement de se poser la question en faisant cela. A condition que cet algo soit bien validé comme étant vraiment sûr.
Mehdi Tibouchi
Jean-Marc Desperrier wrote in message <ih14c7$h62$:
Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par François Grieu, et Thomas Pornin est en train d'y proposer une solution astucieuse au problème : C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un hachage initialisée avec la clé privée et le contenu du message.
C'est une technique classique. Voir par exemple le papier de Louis Granboulan à SCN'02 :
(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose; d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son papier sur PECDSA).
Jean-Marc Desperrier wrote in message
<ih14c7$h62$1@writer.imaginet.fr>:
Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par
François Grieu, et Thomas Pornin est en train d'y proposer une solution
astucieuse au problème :
C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un
hachage initialisée avec la clé privée et le contenu du message.
C'est une technique classique. Voir par exemple le papier de Louis
Granboulan à SCN'02 :
(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose;
d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son
papier sur PECDSA).
Jean-Marc Desperrier wrote in message <ih14c7$h62$:
Il vient d'y avoir une discussion sur le sujet sur sci.crypt initiée par François Grieu, et Thomas Pornin est en train d'y proposer une solution astucieuse au problème : C'est, au lieu d'utiliser un générateur aléatoire, de se servir d'un hachage initialisée avec la clé privée et le contenu du message.
C'est une technique classique. Voir par exemple le papier de Louis Granboulan à SCN'02 :
(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose; d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son papier sur PECDSA).
Thomas Pornin
According to Mehdi Tibouchi :
C'est une technique classique.
Oui, je n'en suis certainement pas l'inventeur. La méthode usuelle consiste à adjoindre à la clé privée une autre valeur secrète qui, combinée avec le message à signer, sert de graine à un PRNG. Ce que j'essaye de faire consiste en deux points :
1. Spécifier une méthode au format "RFC", c'est-à-dire en faisant attention aux détails d'implémentation. Il ne s'agit pas d'innover académiquement mais d'amener la technique à un point où elle est implémentable (et donc, par exemple, publier des vecteurs de test).
2. Réutiliser la clé privée elle-même comme graine pour le PRNG (afin d'être compatible avec des clés déjà générées, et les générateurs de clés existants, sans besoins en stockage supplémentaire).
Le point 2 complique certainement les preuves de sécurité. Dans (EC)DSA, on utilise k (la valeur aléatoire) et x (la clé secrète) dans l'équation suivante :
s = (H(m) + xr) / k mod q
Intuitivement, on "sent" que ça ne pose pas de problème de sécurité si k est généré à partir de H(m) et x, parce que k et x sont séparés par le PRNG. Cela impose que le PRNG ait quelques bonnes proppriétés qu'a priori HMAC_DRBG possède. Mais idéalement il faudrait rédiger la preuve de sécurité proprement (c'est-à-dire adapter les preuves de sécurité existantes pour prendre en compte ce montage). Le format RFC n'est pas très pratique pour ça ; ça m'arrangerait si quelqu'un l'avait déjà fait et publié quelque part...
Voir par exemple le papier de Louis Granboulan à SCN'02 :
(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose; d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son papier sur PECDSA).
Je le note : demander son avis à Louis. Je vais faire ça.
--Thomas Pornin
According to Mehdi Tibouchi <medtib@alussinan.org>:
C'est une technique classique.
Oui, je n'en suis certainement pas l'inventeur. La méthode usuelle
consiste à adjoindre à la clé privée une autre valeur secrète qui,
combinée avec le message à signer, sert de graine à un PRNG. Ce que
j'essaye de faire consiste en deux points :
1. Spécifier une méthode au format "RFC", c'est-à-dire en faisant
attention aux détails d'implémentation. Il ne s'agit pas d'innover
académiquement mais d'amener la technique à un point où elle est
implémentable (et donc, par exemple, publier des vecteurs de test).
2. Réutiliser la clé privée elle-même comme graine pour le PRNG (afin
d'être compatible avec des clés déjà générées, et les générateurs
de clés existants, sans besoins en stockage supplémentaire).
Le point 2 complique certainement les preuves de sécurité. Dans (EC)DSA,
on utilise k (la valeur aléatoire) et x (la clé secrète) dans l'équation
suivante :
s = (H(m) + xr) / k mod q
Intuitivement, on "sent" que ça ne pose pas de problème de sécurité si k
est généré à partir de H(m) et x, parce que k et x sont séparés par le
PRNG. Cela impose que le PRNG ait quelques bonnes proppriétés qu'a
priori HMAC_DRBG possède. Mais idéalement il faudrait rédiger la preuve
de sécurité proprement (c'est-à-dire adapter les preuves de sécurité
existantes pour prendre en compte ce montage). Le format RFC n'est pas
très pratique pour ça ; ça m'arrangerait si quelqu'un l'avait déjà fait
et publié quelque part...
Voir par exemple le papier de Louis Granboulan à SCN'02 :
(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose;
d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son
papier sur PECDSA).
Je le note : demander son avis à Louis. Je vais faire ça.
Oui, je n'en suis certainement pas l'inventeur. La méthode usuelle consiste à adjoindre à la clé privée une autre valeur secrète qui, combinée avec le message à signer, sert de graine à un PRNG. Ce que j'essaye de faire consiste en deux points :
1. Spécifier une méthode au format "RFC", c'est-à-dire en faisant attention aux détails d'implémentation. Il ne s'agit pas d'innover académiquement mais d'amener la technique à un point où elle est implémentable (et donc, par exemple, publier des vecteurs de test).
2. Réutiliser la clé privée elle-même comme graine pour le PRNG (afin d'être compatible avec des clés déjà générées, et les générateurs de clés existants, sans besoins en stockage supplémentaire).
Le point 2 complique certainement les preuves de sécurité. Dans (EC)DSA, on utilise k (la valeur aléatoire) et x (la clé secrète) dans l'équation suivante :
s = (H(m) + xr) / k mod q
Intuitivement, on "sent" que ça ne pose pas de problème de sécurité si k est généré à partir de H(m) et x, parce que k et x sont séparés par le PRNG. Cela impose que le PRNG ait quelques bonnes proppriétés qu'a priori HMAC_DRBG possède. Mais idéalement il faudrait rédiger la preuve de sécurité proprement (c'est-à-dire adapter les preuves de sécurité existantes pour prendre en compte ce montage). Le format RFC n'est pas très pratique pour ça ; ça m'arrangerait si quelqu'un l'avait déjà fait et publié quelque part...
Voir par exemple le papier de Louis Granboulan à SCN'02 :
(qui parlait de ESIGN plutôt que DSA mais ça ne change pas grand-chose; d'ailleurs Louis à aussi une discussion de l'extension à ce cas dans son papier sur PECDSA).
Je le note : demander son avis à Louis. Je vais faire ça.
