j'ai calculé les différents temps d'exécution des algorithmes AES et RSA et voici ce que j'ai obtenu:
AES 128 bits de clé, 2,58 Mo de fichier à chiffrer avec un temps de 203 ms
AES 128 bits de clé, 9,16 Mo de fichier à chiffrer avec un temps de 500 ms et RAM utilisé 21695k
RSA 2048 bits de clé, 2,58 Mo de fichier à chiffrer avec un temps de 21621 ms et RAM 8590 k
RSA 2048 bits de clé, 9,16 Mo de fichier à chiffrer avec un temps de 74583 ms et RAM 22665 k
notez que je calcule juste le temps de l'opération de chiffrement et pas les entrées/sorties(lecture du fichier à chiffré et enregistrement du fichier chiffré) ni la récupération des certificat .cer et .p12 (clé publique et clé privée)
c'est un jeu ou tu sais (pense savoir) de quoi tu parles ??
Non, oui.
l'exposant publique ('e' habituellement) doit satisfaire GCD(p - 1, e) == 1 cette condition est d'autant plus dure à satisfaire que e est grand, à moins que e ne soit premier mais tu n'incluais pas cette hypothèse.
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_ entre 2 et phi(N).
oui disons un nombre premier
Ce n'est pas une condition compliquée à réaliser,
non juste premier cela fera l'affaire
et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est pas elle qui va prendre le plus de temps pendant la génération de clef.
avec un petit test tatitique c'est jouable
je vois bien un "problème RSA standard" résultant du choix de p et q - qui eux sont de tailles comparables - mais moins du choix de e (on évitera quand même de choisir 1 pour donner en clair ce que l'on croyait chiffré), peux-tu détailler ton affirmation ?
Le problème RSA pour e (ou d) petit est, selon toute vraisemblance, plus simple à résoudre que RSA pour e et d aléatoires. Les schémas de chiffrement ou de signature dont la sécurité prouvée repose sur la difficulté du problème RSA standard supposent en général e distribué aléatoirement pour que la réduction fonctionne (cf. par exemple les papiers de Hohenberger et Waters cette année).
bien à partir du moment où tu en as que 2 il est difficile de dire autre chose que "il sont pris au hasard "
mais bon j'ai peut être pas tout compris hein moi les grands mots et les trucs qui font sérieux parsemés d'arguments d'autorité je l'ai comprend pas toujours j'aime bien les trucs accessibles et simples
remy
-- http://remyaumeunier.chez-alice.fr/
Mehdi Tibouchi a écrit :
Sylvain SF wrote in message <4a35924c$0$12637$ba4acef3@news.orange.fr>:
c'est un jeu ou tu sais (pense savoir) de quoi tu parles ??
Non, oui.
l'exposant publique ('e' habituellement) doit satisfaire
GCD(p - 1, e) == 1 cette condition est d'autant plus dure
à satisfaire que e est grand, à moins que e ne soit premier
mais tu n'incluais pas cette hypothèse.
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_
entre 2 et phi(N).
oui disons un nombre premier
Ce n'est pas une condition compliquée à réaliser,
non juste premier cela fera l'affaire
et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est
pas elle qui va prendre le plus de temps pendant la génération de clef.
avec un petit test tatitique c'est jouable
je vois bien un "problème RSA standard" résultant du choix de p et q -
qui eux sont de tailles comparables - mais moins du choix de e (on
évitera quand même de choisir 1 pour donner en clair ce que l'on
croyait chiffré), peux-tu détailler ton affirmation ?
Le problème RSA pour e (ou d) petit est, selon toute vraisemblance, plus
simple à résoudre que RSA pour e et d aléatoires. Les schémas de
chiffrement ou de signature dont la sécurité prouvée repose sur la
difficulté du problème RSA standard supposent en général e distribué
aléatoirement pour que la réduction fonctionne (cf. par exemple
les papiers de Hohenberger et Waters cette année).
bien à partir du moment où tu en as que 2 il est difficile de dire
autre chose que "il sont pris au hasard "
mais bon j'ai peut être pas tout compris hein
moi les grands mots et les trucs qui font sérieux parsemés d'arguments
d'autorité je l'ai comprend pas toujours j'aime bien les trucs
accessibles et simples
c'est un jeu ou tu sais (pense savoir) de quoi tu parles ??
Non, oui.
l'exposant publique ('e' habituellement) doit satisfaire GCD(p - 1, e) == 1 cette condition est d'autant plus dure à satisfaire que e est grand, à moins que e ne soit premier mais tu n'incluais pas cette hypothèse.
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_ entre 2 et phi(N).
oui disons un nombre premier
Ce n'est pas une condition compliquée à réaliser,
non juste premier cela fera l'affaire
et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est pas elle qui va prendre le plus de temps pendant la génération de clef.
avec un petit test tatitique c'est jouable
je vois bien un "problème RSA standard" résultant du choix de p et q - qui eux sont de tailles comparables - mais moins du choix de e (on évitera quand même de choisir 1 pour donner en clair ce que l'on croyait chiffré), peux-tu détailler ton affirmation ?
Le problème RSA pour e (ou d) petit est, selon toute vraisemblance, plus simple à résoudre que RSA pour e et d aléatoires. Les schémas de chiffrement ou de signature dont la sécurité prouvée repose sur la difficulté du problème RSA standard supposent en général e distribué aléatoirement pour que la réduction fonctionne (cf. par exemple les papiers de Hohenberger et Waters cette année).
bien à partir du moment où tu en as que 2 il est difficile de dire autre chose que "il sont pris au hasard "
mais bon j'ai peut être pas tout compris hein moi les grands mots et les trucs qui font sérieux parsemés d'arguments d'autorité je l'ai comprend pas toujours j'aime bien les trucs accessibles et simples
remy
-- http://remyaumeunier.chez-alice.fr/
Sylvain SF
Mehdi Tibouchi a écrit :
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_ entre 2 et phi(N). Ce n'est pas une condition compliquée à réaliser, et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est pas elle qui va prendre le plus de temps pendant la génération de clef.
ce n'est pas dur, mais c'est loin d'être appliqué "dans la vraie vie".
la génération de e prend un temps nul, la vérification de sa primalité prend un temps non négligeable devant les tests sur p et q qui de longueur moitié sont testé plus rapidement.
Le problème RSA pour e (ou d) petit est, selon toute vraisemblance, plus simple à résoudre que RSA pour e et d aléatoires. Les schémas de chiffrement ou de signature dont la sécurité prouvée repose sur la difficulté du problème RSA standard supposent en général e distribué aléatoirement pour que la réduction fonctionne (cf. par exemple les papiers de Hohenberger et Waters cette année).
e petit est "selon toute vraisemblance" un risque permettant de forger "plus facilement" des signatures, je vois moins où c'est génant pour du wrapping.
parles-tu de "Realizing Hash-n-Sign Signatures under Std Assumptions" ?
Sylvain.
Mehdi Tibouchi a écrit :
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_
entre 2 et phi(N). Ce n'est pas une condition compliquée à réaliser, et
elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est
pas elle qui va prendre le plus de temps pendant la génération de clef.
ce n'est pas dur, mais c'est loin d'être appliqué "dans la vraie vie".
la génération de e prend un temps nul, la vérification de sa primalité
prend un temps non négligeable devant les tests sur p et q qui de
longueur moitié sont testé plus rapidement.
Le problème RSA pour e (ou d) petit est, selon toute vraisemblance, plus
simple à résoudre que RSA pour e et d aléatoires. Les schémas de
chiffrement ou de signature dont la sécurité prouvée repose sur la
difficulté du problème RSA standard supposent en général e distribué
aléatoirement pour que la réduction fonctionne (cf. par exemple
les papiers de Hohenberger et Waters cette année).
e petit est "selon toute vraisemblance" un risque permettant de forger
"plus facilement" des signatures, je vois moins où c'est génant pour
du wrapping.
parles-tu de "Realizing Hash-n-Sign Signatures under Std Assumptions" ?
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_ entre 2 et phi(N). Ce n'est pas une condition compliquée à réaliser, et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est pas elle qui va prendre le plus de temps pendant la génération de clef.
ce n'est pas dur, mais c'est loin d'être appliqué "dans la vraie vie".
la génération de e prend un temps nul, la vérification de sa primalité prend un temps non négligeable devant les tests sur p et q qui de longueur moitié sont testé plus rapidement.
Le problème RSA pour e (ou d) petit est, selon toute vraisemblance, plus simple à résoudre que RSA pour e et d aléatoires. Les schémas de chiffrement ou de signature dont la sécurité prouvée repose sur la difficulté du problème RSA standard supposent en général e distribué aléatoirement pour que la réduction fonctionne (cf. par exemple les papiers de Hohenberger et Waters cette année).
e petit est "selon toute vraisemblance" un risque permettant de forger "plus facilement" des signatures, je vois moins où c'est génant pour du wrapping.
parles-tu de "Realizing Hash-n-Sign Signatures under Std Assumptions" ?
Sylvain.
Erwan David
Sylvain SF écrivait :
Mehdi Tibouchi a écrit :
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_ entre 2 et phi(N). Ce n'est pas une condition compliquée à réaliser, et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est pas elle qui va prendre le plus de temps pendant la génération de clef.
ce n'est pas dur, mais c'est loin d'être appliqué "dans la vraie vie".
la génération de e prend un temps nul, la vérification de sa primalité prend un temps non négligeable devant les tests sur p et q qui de longueur moitié sont testé plus rapidement.
Dans la vraie vie, e=3, 17 ou 65537
parceque pour aller vite il ne faut pas qu'il soit trop grand, quand il est premeier on est sûr qu'il convient, et moins il a de bits à 1 plus vite vont les opérations sur clef publique.
Je pense que tu confonds avec d qui se déduit de e, p et q.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Sylvain SF <sylvain@boiteaspam.info> écrivait :
Mehdi Tibouchi a écrit :
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_
entre 2 et phi(N). Ce n'est pas une condition compliquée à réaliser, et
elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est
pas elle qui va prendre le plus de temps pendant la génération de clef.
ce n'est pas dur, mais c'est loin d'être appliqué "dans la vraie vie".
la génération de e prend un temps nul, la vérification de sa primalité
prend un temps non négligeable devant les tests sur p et q qui de
longueur moitié sont testé plus rapidement.
Dans la vraie vie, e=3, 17 ou 65537
parceque pour aller vite il ne faut pas qu'il soit trop grand, quand il
est premeier on est sûr qu'il convient, et moins il a de bits à 1 plus
vite vont les opérations sur clef publique.
Je pense que tu confonds avec d qui se déduit de e, p et q.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
L'exposant e est choisi aléatoire parmi les nombres _premiers à phi(N)_ entre 2 et phi(N). Ce n'est pas une condition compliquée à réaliser, et elle n'est pas spécialement plus dure à satisfaire pour e grand. Ce n'est pas elle qui va prendre le plus de temps pendant la génération de clef.
ce n'est pas dur, mais c'est loin d'être appliqué "dans la vraie vie".
la génération de e prend un temps nul, la vérification de sa primalité prend un temps non négligeable devant les tests sur p et q qui de longueur moitié sont testé plus rapidement.
Dans la vraie vie, e=3, 17 ou 65537
parceque pour aller vite il ne faut pas qu'il soit trop grand, quand il est premeier on est sûr qu'il convient, et moins il a de bits à 1 plus vite vont les opérations sur clef publique.
Je pense que tu confonds avec d qui se déduit de e, p et q.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas Pornin
According to Erwan David :
Dans la vraie vie, e=3, 17 ou 65537
Et toujours dans la vraie vie, choisir un e qui ne tient pas sur 32 bits, c'est chercher les ennuis. Par exemple, la couche cryptographique interne à Windows, quand elle manipule une clé publique RSA, affecte joyeusement un mot de 32 bits pour e, pas plus.
--Thomas Pornin
According to Erwan David <erwan@rail.eu.org>:
Dans la vraie vie, e=3, 17 ou 65537
Et toujours dans la vraie vie, choisir un e qui ne tient pas sur 32
bits, c'est chercher les ennuis. Par exemple, la couche cryptographique
interne à Windows, quand elle manipule une clé publique RSA, affecte
joyeusement un mot de 32 bits pour e, pas plus.
Et toujours dans la vraie vie, choisir un e qui ne tient pas sur 32 bits, c'est chercher les ennuis. Par exemple, la couche cryptographique interne à Windows, quand elle manipule une clé publique RSA, affecte joyeusement un mot de 32 bits pour e, pas plus.
--Thomas Pornin
Erwan David
Thomas Pornin écrivait :
According to Erwan David :
Dans la vraie vie, e=3, 17 ou 65537
Et toujours dans la vraie vie, choisir un e qui ne tient pas sur 32 bits, c'est chercher les ennuis. Par exemple, la couche cryptographique interne à Windows, quand elle manipule une clé publique RSA, affecte joyeusement un mot de 32 bits pour e, pas plus.
Et c'est pas la seule...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas Pornin <pornin@bolet.org> écrivait :
According to Erwan David <erwan@rail.eu.org>:
Dans la vraie vie, e=3, 17 ou 65537
Et toujours dans la vraie vie, choisir un e qui ne tient pas sur 32
bits, c'est chercher les ennuis. Par exemple, la couche cryptographique
interne à Windows, quand elle manipule une clé publique RSA, affecte
joyeusement un mot de 32 bits pour e, pas plus.
Et c'est pas la seule...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Et toujours dans la vraie vie, choisir un e qui ne tient pas sur 32 bits, c'est chercher les ennuis. Par exemple, la couche cryptographique interne à Windows, quand elle manipule une clé publique RSA, affecte joyeusement un mot de 32 bits pour e, pas plus.
Et c'est pas la seule...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Sylvain SF
Thomas Pornin a écrit :
la couche cryptographique interne à Windows
quelle couche (BaseCSP, EnhCSP, CNG, ...) de quel windows ?
un XP SP3 avec ses CSP par défaut gère en effet très mal les exp. publics longs (stockage des certs n'importe où et échec de vérification).
SF.
Thomas Pornin a écrit :
la couche cryptographique interne à Windows
quelle couche (BaseCSP, EnhCSP, CNG, ...) de quel windows ?
un XP SP3 avec ses CSP par défaut gère en effet très mal les
exp. publics longs (stockage des certs n'importe où et échec de
vérification).
quelle couche (BaseCSP, EnhCSP, CNG, ...) de quel windows ?
un XP SP3 avec ses CSP par défaut gère en effet très mal les exp. publics longs (stockage des certs n'importe où et échec de vérification).
SF.
Thomas Pornin
According to Sylvain SF :
quelle couche (BaseCSP, EnhCSP, CNG, ...) de quel windows ?
Les CSP. La doc que j'ai sous la main (le "platform SDK") couvre jusqu'à Windows Server 2003 R2 et tous les CSP décrits (Base, Strong, Enhanced, AES, RSA/Schannel) utilisent le même format pour exporter ou importer une clé publique ; ce format contient une structure nommée "RSAPUBKEY", laquelle a un champ de 32 bits pour l'exposant publique.
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une clé _privée_ RSA, alors des restrictions additionnelles s'appliquent : taille multiple de 16, exactement deux facteurs premiers, et la taille de chaque facteur doit être précisément la moitié de celle du module.
--Thomas Pornin
According to Sylvain SF <sylvain@boiteaspam.info>:
quelle couche (BaseCSP, EnhCSP, CNG, ...) de quel windows ?
Les CSP. La doc que j'ai sous la main (le "platform SDK") couvre jusqu'à
Windows Server 2003 R2 et tous les CSP décrits (Base, Strong, Enhanced,
AES, RSA/Schannel) utilisent le même format pour exporter ou importer
une clé publique ; ce format contient une structure nommée "RSAPUBKEY",
laquelle a un champ de 32 bits pour l'exposant publique.
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la
clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une
clé _privée_ RSA, alors des restrictions additionnelles s'appliquent :
taille multiple de 16, exactement deux facteurs premiers, et la taille
de chaque facteur doit être précisément la moitié de celle du module.
quelle couche (BaseCSP, EnhCSP, CNG, ...) de quel windows ?
Les CSP. La doc que j'ai sous la main (le "platform SDK") couvre jusqu'à Windows Server 2003 R2 et tous les CSP décrits (Base, Strong, Enhanced, AES, RSA/Schannel) utilisent le même format pour exporter ou importer une clé publique ; ce format contient une structure nommée "RSAPUBKEY", laquelle a un champ de 32 bits pour l'exposant publique.
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une clé _privée_ RSA, alors des restrictions additionnelles s'appliquent : taille multiple de 16, exactement deux facteurs premiers, et la taille de chaque facteur doit être précisément la moitié de celle du module.
--Thomas Pornin
Sylvain SF
Thomas Pornin a écrit :
Les CSP. La doc que j'ai sous la main (le "platform SDK") couvre jusqu'à Windows Server 2003 R2 et tous les CSP décrits (Base, Strong, Enhanced, AES, RSA/Schannel) utilisent le même format pour exporter ou importer une clé publique ; ce format contient une structure nommée "RSAPUBKEY", laquelle a un champ de 32 bits pour l'exposant publique.
ok, merci pour la (mauvaise) nouvelle. j'éplucherais la doc CNG à temps perdu.
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une clé _privée_ RSA, alors des restrictions additionnelles s'appliquent : taille multiple de 16, exactement deux facteurs premiers, et la taille de chaque facteur doit être précisément la moitié de celle du module.
oui, déjà observé son aversion pour des p / q de longueur dissemblable.
Sylvain.
Thomas Pornin a écrit :
Les CSP. La doc que j'ai sous la main (le "platform SDK") couvre jusqu'à
Windows Server 2003 R2 et tous les CSP décrits (Base, Strong, Enhanced,
AES, RSA/Schannel) utilisent le même format pour exporter ou importer
une clé publique ; ce format contient une structure nommée "RSAPUBKEY",
laquelle a un champ de 32 bits pour l'exposant publique.
ok, merci pour la (mauvaise) nouvelle. j'éplucherais la doc CNG à
temps perdu.
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la
clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une
clé _privée_ RSA, alors des restrictions additionnelles s'appliquent :
taille multiple de 16, exactement deux facteurs premiers, et la taille
de chaque facteur doit être précisément la moitié de celle du module.
oui, déjà observé son aversion pour des p / q de longueur dissemblable.
Les CSP. La doc que j'ai sous la main (le "platform SDK") couvre jusqu'à Windows Server 2003 R2 et tous les CSP décrits (Base, Strong, Enhanced, AES, RSA/Schannel) utilisent le même format pour exporter ou importer une clé publique ; ce format contient une structure nommée "RSAPUBKEY", laquelle a un champ de 32 bits pour l'exposant publique.
ok, merci pour la (mauvaise) nouvelle. j'éplucherais la doc CNG à temps perdu.
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une clé _privée_ RSA, alors des restrictions additionnelles s'appliquent : taille multiple de 16, exactement deux facteurs premiers, et la taille de chaque facteur doit être précisément la moitié de celle du module.
oui, déjà observé son aversion pour des p / q de longueur dissemblable.
Sylvain.
Erwan David
Thomas Pornin écrivait :
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une clé _privée_ RSA, alors des restrictions additionnelles s'appliquent : taille multiple de 16, exactement deux facteurs premiers, et la taille de chaque facteur doit être précisément la moitié de celle du module.
Ça facilite l'implémentation des reste chinois... J'ai vu les même contraintes sur des crypto-processeurs embarqués (sur carte à puce ou terminaux de paiement).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Thomas Pornin <pornin@bolet.org> écrivait :
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la
clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une
clé _privée_ RSA, alors des restrictions additionnelles s'appliquent :
taille multiple de 16, exactement deux facteurs premiers, et la taille
de chaque facteur doit être précisément la moitié de celle du module.
Ça facilite l'implémentation des reste chinois... J'ai vu les même
contraintes sur des crypto-processeurs embarqués (sur carte à puce ou
terminaux de paiement).
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Dans un genre proche, ces mêmes CSP n'aiment pas quand la longueur de la clé n'est pas un multiple de 8. Si on veut s'en servir pour gérer une clé _privée_ RSA, alors des restrictions additionnelles s'appliquent : taille multiple de 16, exactement deux facteurs premiers, et la taille de chaque facteur doit être précisément la moitié de celle du module.
Ça facilite l'implémentation des reste chinois... J'ai vu les même contraintes sur des crypto-processeurs embarqués (sur carte à puce ou terminaux de paiement).
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Mehdi Tibouchi
Erwan David wrote in message :
Ça facilite l'implémentation des reste chinois... J'ai vu les même contraintes sur des crypto-processeurs embarqués (sur carte à puce ou terminaux de paiement).
Argh, des restes chinois dans de l'embarqué ? Et les attaques par fautes ?
Erwan David wrote in message
<m2ski04uz3.fsf@minuetto.depot.rail.eu.org>:
Ça facilite l'implémentation des reste chinois... J'ai vu les même
contraintes sur des crypto-processeurs embarqués (sur carte à puce ou
terminaux de paiement).
Argh, des restes chinois dans de l'embarqué ? Et les attaques par
fautes ?
Ça facilite l'implémentation des reste chinois... J'ai vu les même contraintes sur des crypto-processeurs embarqués (sur carte à puce ou terminaux de paiement).
Argh, des restes chinois dans de l'embarqué ? Et les attaques par fautes ?
