[ECDSA] pourquoi je peux pas utiliser n'importe quelle taille pour mes clés ???
4 réponses
Elleuch Amine
Bonsoir,
J'ai écrit un petit programme de signature de fichiers en utilisant la
librairie BouncyCastle (java) et l'algo ECDSA (utilsant les courbes
elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir
n'importe quelle taille de clé dans mon programme ? il y a *apparemment*
une liste très précise de tailles de clés qui est suppotée. Pour les
autres, j'obtiens une exception "java.lang.IllegalStateException: EC Key
Pair Generator not initialised". Cette liste comporte par exemple {162,
192, 239, 256 }. Si j'essaie de créer une paire de clé de taille 161 par
exemple, j'ai droit à la belle exception que j'ai mise un peu plus haut
;(. A quoi cela est dû ?? Y'a des raisons théoriques qui rendent
l'utilisation des certaines tailles de clés impossible ? Et ou est ce
que je peux obtenir la _liste_ complète (s'il y en a) des tailles des
clés pouvant être utilisés ?
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
Ludovic FLAMENT
Bonsoir,
J'ai écrit un petit programme de signature de fichiers en utilisant la librairie BouncyCastle (java) et l'algo ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir n'importe quelle taille de clé dans mon programme ? il y a *apparemment* une liste très précise de tailles de clés qui est suppotée. Pour les autres, j'obtiens une exception "java.lang.IllegalStateException: EC Key Pair Generator not initialised". Cette liste comporte par exemple {162, 192, 239, 256 }.
Ce doit être les tailles recommandées (imposées) pour les courbes prédéfinies dans la librairie
Si j'essaie de créer une paire de clé de taille 161 par exemple, j'ai droit à la belle exception que j'ai mise un peu plus haut ;(. A quoi cela est dû ??
Une fois de plus, tu utilises une librairie qui ne semble pas de bonne qualité ou que tu utilises incorrectement ;-)
Si la librairie ne supporte pas des tailles de clef "dynamiques", elle ne doit pas le proposer dans son API !?
Y'a des raisons théoriques qui rendent l'utilisation des certaines tailles de clés impossible ? Non, dans la mesure où il n'y a pas de restriction sur la taille des
clefs privées. Il faut tout de même respecter le fait que la taille de la clef privée (un entier) soit comprise en 1 et la taille de l'ordre du point qui définie la courbe et qui un paramètre de la courbe que tu utilises.
De manière logique et pour des raisons de performances, on utilise une taille de clef qui soit la plus proche possible de la taille de l'ordre du point (taille de r - 1 bits par exemple). Il est en effet inutile d'utiliser une courbe définie sur un corps fini de taille 512 bits pour générer une clef de 100 bits.
De la même manière on génère des clefs de 256 bits (et pas des clefs de 100 bits) quand on fait de l'AES 256.
Et ou est ce que je peux obtenir la _liste_ complète (s'il y en a) des tailles des clés pouvant être utilisés ?
Cela n'existe pas.
Pour info, voici la méthode de génération de clef (ECC) recommandée par la norme IEEE 1363-2000
An Algorithm for Generating EC Keys Input: valid EC parameters q, a, b, r, and G. Output: a public key W, a private key s
1. Generate an integer s in the range 0 < s < r designed to be hard for an adversary to guess (e.g., a random integer). 2. Compute the point W by scalar multiplication: W = sG. 3. Output W and s.
J'ai écrit un petit programme de signature de fichiers en utilisant la
librairie BouncyCastle (java) et l'algo ECDSA (utilsant les courbes
elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir
n'importe quelle taille de clé dans mon programme ? il y a *apparemment*
une liste très précise de tailles de clés qui est suppotée. Pour les
autres, j'obtiens une exception "java.lang.IllegalStateException: EC Key
Pair Generator not initialised". Cette liste comporte par exemple {162,
192, 239, 256 }.
Ce doit être les tailles recommandées (imposées) pour les courbes
prédéfinies dans la librairie
Si j'essaie de créer une paire de clé de taille 161 par
exemple, j'ai droit à la belle exception que j'ai mise un peu plus haut
;(. A quoi cela est dû ??
Une fois de plus, tu utilises une librairie qui ne semble pas de bonne
qualité ou que tu utilises incorrectement ;-)
Si la librairie ne supporte pas des tailles de clef "dynamiques", elle
ne doit pas le proposer dans son API !?
Y'a des raisons théoriques qui rendent l'utilisation des certaines tailles de clés impossible ?
Non, dans la mesure où il n'y a pas de restriction sur la taille des
clefs privées. Il faut tout de même respecter le fait que la taille de
la clef privée (un entier) soit comprise en 1 et la taille de l'ordre du
point qui définie la courbe et qui un paramètre de la courbe que tu
utilises.
De manière logique et pour des raisons de performances, on utilise une
taille de clef qui soit la plus proche possible de la taille de l'ordre
du point (taille de r - 1 bits par exemple). Il est en effet inutile
d'utiliser une courbe définie sur un corps fini de taille 512 bits pour
générer une clef de 100 bits.
De la même manière on génère des clefs de 256 bits (et pas des clefs de
100 bits) quand on fait de l'AES 256.
Et ou est ce que je peux obtenir la _liste_ complète (s'il y en a) des tailles des clés pouvant être utilisés ?
Cela n'existe pas.
Pour info, voici la méthode de génération de clef (ECC) recommandée par
la norme IEEE 1363-2000
An Algorithm for Generating EC Keys
Input: valid EC parameters q, a, b, r, and G.
Output: a public key W, a private key s
1. Generate an integer s in the range 0 < s < r designed to be hard
for an adversary to guess (e.g., a random integer).
2. Compute the point W by scalar multiplication: W = sG.
3. Output W and s.
J'ai écrit un petit programme de signature de fichiers en utilisant la librairie BouncyCastle (java) et l'algo ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir n'importe quelle taille de clé dans mon programme ? il y a *apparemment* une liste très précise de tailles de clés qui est suppotée. Pour les autres, j'obtiens une exception "java.lang.IllegalStateException: EC Key Pair Generator not initialised". Cette liste comporte par exemple {162, 192, 239, 256 }.
Ce doit être les tailles recommandées (imposées) pour les courbes prédéfinies dans la librairie
Si j'essaie de créer une paire de clé de taille 161 par exemple, j'ai droit à la belle exception que j'ai mise un peu plus haut ;(. A quoi cela est dû ??
Une fois de plus, tu utilises une librairie qui ne semble pas de bonne qualité ou que tu utilises incorrectement ;-)
Si la librairie ne supporte pas des tailles de clef "dynamiques", elle ne doit pas le proposer dans son API !?
Y'a des raisons théoriques qui rendent l'utilisation des certaines tailles de clés impossible ? Non, dans la mesure où il n'y a pas de restriction sur la taille des
clefs privées. Il faut tout de même respecter le fait que la taille de la clef privée (un entier) soit comprise en 1 et la taille de l'ordre du point qui définie la courbe et qui un paramètre de la courbe que tu utilises.
De manière logique et pour des raisons de performances, on utilise une taille de clef qui soit la plus proche possible de la taille de l'ordre du point (taille de r - 1 bits par exemple). Il est en effet inutile d'utiliser une courbe définie sur un corps fini de taille 512 bits pour générer une clef de 100 bits.
De la même manière on génère des clefs de 256 bits (et pas des clefs de 100 bits) quand on fait de l'AES 256.
Et ou est ce que je peux obtenir la _liste_ complète (s'il y en a) des tailles des clés pouvant être utilisés ?
Cela n'existe pas.
Pour info, voici la méthode de génération de clef (ECC) recommandée par la norme IEEE 1363-2000
An Algorithm for Generating EC Keys Input: valid EC parameters q, a, b, r, and G. Output: a public key W, a private key s
1. Generate an integer s in the range 0 < s < r designed to be hard for an adversary to guess (e.g., a random integer). 2. Compute the point W by scalar multiplication: W = sG. 3. Output W and s.
ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir n'importe quelle taille de clé dans mon programme ? il y a *apparemment* une liste très précise de tailles de clés qui est supportée.
ECDSA travaille sur une courbe elliptique, qui est un objet mathématique un peu compliqué. Pour être utilisable pour des besoins cryptographiques, il faut que le nombre exact de points faisant partie de la courbe soit connu, et si possible que ce nombre soit premier.
Compter les points sur une courbe n'est pas une chose évidente. Il y a eu des avancées récemment sur le sujet (notamment une méthode rapide de Harley et Mestre) mais ça reste assez lourd, notamment en taille de code. Aussi, les bibliothèques usuelles se contentent d'utiliser un jeu restreint et précalculé de courbes elliptiques, en général celles publiés par le NIST (dans FIPS 186-2-change1). Utiliser une même courbe pour beaucoup de paires de clés ne pose pas de problème de sécurité.
À chaque courbe correspond _une_ taille de clé. D'où la limitation.
--Thomas Pornin
According to Elleuch Amine <elleuch@telecom-paris.fr>:
ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit
problème. Je peux pas choisir n'importe quelle taille de clé dans mon
programme ? il y a *apparemment* une liste très précise de tailles de
clés qui est supportée.
ECDSA travaille sur une courbe elliptique, qui est un objet
mathématique un peu compliqué. Pour être utilisable pour des besoins
cryptographiques, il faut que le nombre exact de points faisant partie
de la courbe soit connu, et si possible que ce nombre soit premier.
Compter les points sur une courbe n'est pas une chose évidente. Il y a
eu des avancées récemment sur le sujet (notamment une méthode rapide
de Harley et Mestre) mais ça reste assez lourd, notamment en taille de
code. Aussi, les bibliothèques usuelles se contentent d'utiliser un
jeu restreint et précalculé de courbes elliptiques, en général celles
publiés par le NIST (dans FIPS 186-2-change1). Utiliser une même courbe
pour beaucoup de paires de clés ne pose pas de problème de sécurité.
À chaque courbe correspond _une_ taille de clé. D'où la limitation.
ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir n'importe quelle taille de clé dans mon programme ? il y a *apparemment* une liste très précise de tailles de clés qui est supportée.
ECDSA travaille sur une courbe elliptique, qui est un objet mathématique un peu compliqué. Pour être utilisable pour des besoins cryptographiques, il faut que le nombre exact de points faisant partie de la courbe soit connu, et si possible que ce nombre soit premier.
Compter les points sur une courbe n'est pas une chose évidente. Il y a eu des avancées récemment sur le sujet (notamment une méthode rapide de Harley et Mestre) mais ça reste assez lourd, notamment en taille de code. Aussi, les bibliothèques usuelles se contentent d'utiliser un jeu restreint et précalculé de courbes elliptiques, en général celles publiés par le NIST (dans FIPS 186-2-change1). Utiliser une même courbe pour beaucoup de paires de clés ne pose pas de problème de sécurité.
À chaque courbe correspond _une_ taille de clé. D'où la limitation.
--Thomas Pornin
Elleuch Amine
Et ou est ce que je peux obtenir la _liste_ complète (s'il y en a) des tailles des clés pouvant être utilisés ?
Cela n'existe pas.
Bon courage,
Merci beaucoup de votre réponse, Ca m'a beaucoup aidé
Et ou est ce que je peux obtenir la _liste_ complète (s'il y en a) des
tailles des clés pouvant être utilisés ?
Cela n'existe pas.
Bon courage,
Merci beaucoup de votre réponse, Ca m'a beaucoup aidé
Et ou est ce que je peux obtenir la _liste_ complète (s'il y en a) des tailles des clés pouvant être utilisés ?
Cela n'existe pas.
Bon courage,
Merci beaucoup de votre réponse, Ca m'a beaucoup aidé
Elleuch Amine
According to Elleuch Amine :
ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir n'importe quelle taille de clé dans mon programme ? il y a *apparemment* une liste très précise de tailles de clés qui est supportée.
ECDSA travaille sur une courbe elliptique, qui est un objet mathématique un peu compliqué. Pour être utilisable pour des besoins cryptographiques, il faut que le nombre exact de points faisant partie de la courbe soit connu, et si possible que ce nombre soit premier.
Compter les points sur une courbe n'est pas une chose évidente. Il y a eu des avancées récemment sur le sujet (notamment une méthode rapide de Harley et Mestre) mais ça reste assez lourd, notamment en taille de code. Aussi, les bibliothèques usuelles se contentent d'utiliser un jeu restreint et précalculé de courbes elliptiques, en général celles publiés par le NIST (dans FIPS 186-2-change1). Utiliser une même courbe pour beaucoup de paires de clés ne pose pas de problème de sécurité.
À chaque courbe correspond _une_ taille de clé. D'où la limitation.
--Thomas Pornin
Merci de votre réponse
According to Elleuch Amine <elleuch@telecom-paris.fr>:
ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit
problème. Je peux pas choisir n'importe quelle taille de clé dans mon
programme ? il y a *apparemment* une liste très précise de tailles de
clés qui est supportée.
ECDSA travaille sur une courbe elliptique, qui est un objet
mathématique un peu compliqué. Pour être utilisable pour des besoins
cryptographiques, il faut que le nombre exact de points faisant partie
de la courbe soit connu, et si possible que ce nombre soit premier.
Compter les points sur une courbe n'est pas une chose évidente. Il y a
eu des avancées récemment sur le sujet (notamment une méthode rapide
de Harley et Mestre) mais ça reste assez lourd, notamment en taille de
code. Aussi, les bibliothèques usuelles se contentent d'utiliser un
jeu restreint et précalculé de courbes elliptiques, en général celles
publiés par le NIST (dans FIPS 186-2-change1). Utiliser une même courbe
pour beaucoup de paires de clés ne pose pas de problème de sécurité.
À chaque courbe correspond _une_ taille de clé. D'où la limitation.
ECDSA (utilsant les courbes elliptiques). Cependant, j'ai un petit problème. Je peux pas choisir n'importe quelle taille de clé dans mon programme ? il y a *apparemment* une liste très précise de tailles de clés qui est supportée.
ECDSA travaille sur une courbe elliptique, qui est un objet mathématique un peu compliqué. Pour être utilisable pour des besoins cryptographiques, il faut que le nombre exact de points faisant partie de la courbe soit connu, et si possible que ce nombre soit premier.
Compter les points sur une courbe n'est pas une chose évidente. Il y a eu des avancées récemment sur le sujet (notamment une méthode rapide de Harley et Mestre) mais ça reste assez lourd, notamment en taille de code. Aussi, les bibliothèques usuelles se contentent d'utiliser un jeu restreint et précalculé de courbes elliptiques, en général celles publiés par le NIST (dans FIPS 186-2-change1). Utiliser une même courbe pour beaucoup de paires de clés ne pose pas de problème de sécurité.
À chaque courbe correspond _une_ taille de clé. D'où la limitation.
