Une bi-clé, 2 certificats sur la même bi-clé et cryptage, question ...
1 réponse
neopale
Bonjour,
Voici mon problème en qqes points :
0 - J'ai une "mini" PKI basée sur OpenSSL et qqes scripts qui vont bien.
1 - Je génère une bi-clé (RSA 3DES et 1024b)
2 - Je créée le CSR
3 - Je signe la CSR par la CA et j'ai mon certificat correspondant à mes clés...
4 - Au passage, je fabrique un pkcs12 (ou pfx) contenant le certif et la clé privé
Je crypte un fichier avec ce certif via la clé publique bien sur puis je décrypte en passant en paramètre le p12 --> Ok tout est propre. Je conserve ce fichier crypté dans 1 coin.
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de validité de mon certif. Je souhaitais simplement regénérer une CSR puis signature etc... à partir de la même bi-clé et du même DN puis décrypter mon fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1) avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
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
Bruno Tréguier
Le 19/02/2010 à 19:38, neopale a écrit :
Bonjour,
Bonjour,
[...]
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de validité de mon certif. Je souhaitais simplement regénérer une CSR puis signature etc... à partir de la même bi-clé et du même DN puis décrypter mon fichier stocké dans 1 coin. Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1) avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Merci par avance
Il y a des choses que je ne comprends pas bien dans votre raisonnement:
1) à mon sens, le seul motif valable de garder le même bi-clef serait l'arrivée à péremption de votre certificat. Dans tous les autres cas (départ de la personne concernée, changement de fonction, ou pire: compromission de la clef privée), il y a lieu de générer un nouveau bi-clef !
2) si vous gardez le même bi-clef, le même DN, et les mêmes attributs, le CSR sera également identique, pas la peine de le refaire... Seul le certificat sera différent (parce qu'il est horodaté et que le numéro de série est différent).
3) cela dit, si les conditions évoquées dans votre message sont réunies (même bi-clef, même DN, etc.), il n'y a aucune raison pour que vous ne puissiez pas déchiffrer votre fichier (et c'est bien le souci d'ailleurs, et la raison même de la nécessité de changer le bi-clef en cas de révocation du certif pour d'autres raisons que la péremption simple).
4) utiliser de la crypto asymétrique seule pour chiffrer n'est pas la meilleure solution (à moins que votre exemple ne soit qu'un exemple, justement): la lenteur de cette méthode vous limitera assez rapidement au niveau de la taille des fichiers.
Pourriez-vous décrire les suites de commandes que vous avez utilisées pour créer vos certificats, et celles concernant le chiffrement/déchiffrement du fichier, ainsi que les messages d'erreur éventuels (parce "ça pète", c'est un peu sec ;-) ).
Cordialement,
Bruno Tréguier
Le 19/02/2010 à 19:38, neopale a écrit :
Bonjour,
Bonjour,
[...]
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de
validité de mon certif. Je souhaitais simplement regénérer une CSR puis
signature etc... à partir de la même bi-clé et du même DN puis décrypter mon
fichier stocké dans 1 coin.
Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1)
avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Merci par avance
Il y a des choses que je ne comprends pas bien dans votre raisonnement:
1) à mon sens, le seul motif valable de garder le même bi-clef serait
l'arrivée à péremption de votre certificat. Dans tous les autres cas
(départ de la personne concernée, changement de fonction, ou pire:
compromission de la clef privée), il y a lieu de générer un nouveau
bi-clef !
2) si vous gardez le même bi-clef, le même DN, et les mêmes attributs,
le CSR sera également identique, pas la peine de le refaire... Seul le
certificat sera différent (parce qu'il est horodaté et que le numéro de
série est différent).
3) cela dit, si les conditions évoquées dans votre message sont réunies
(même bi-clef, même DN, etc.), il n'y a aucune raison pour que vous ne
puissiez pas déchiffrer votre fichier (et c'est bien le souci
d'ailleurs, et la raison même de la nécessité de changer le bi-clef en
cas de révocation du certif pour d'autres raisons que la péremption simple).
4) utiliser de la crypto asymétrique seule pour chiffrer n'est pas la
meilleure solution (à moins que votre exemple ne soit qu'un exemple,
justement): la lenteur de cette méthode vous limitera assez rapidement
au niveau de la taille des fichiers.
Pourriez-vous décrire les suites de commandes que vous avez utilisées
pour créer vos certificats, et celles concernant le
chiffrement/déchiffrement du fichier, ainsi que les messages d'erreur
éventuels (parce "ça pète", c'est un peu sec ;-) ).
Maintenant, mon problème : je me pose dans la situation de la révocation/fin de validité de mon certif. Je souhaitais simplement regénérer une CSR puis signature etc... à partir de la même bi-clé et du même DN puis décrypter mon fichier stocké dans 1 coin. Effectivement si je tente de décrypter le fichier crypté (avec le certif N°1) avec le certif N°2 qui a la même bi-clé et bien ca pete !!!
Qui pourrait me donner 1 explication du pourquoi ?
Merci par avance
Il y a des choses que je ne comprends pas bien dans votre raisonnement:
1) à mon sens, le seul motif valable de garder le même bi-clef serait l'arrivée à péremption de votre certificat. Dans tous les autres cas (départ de la personne concernée, changement de fonction, ou pire: compromission de la clef privée), il y a lieu de générer un nouveau bi-clef !
2) si vous gardez le même bi-clef, le même DN, et les mêmes attributs, le CSR sera également identique, pas la peine de le refaire... Seul le certificat sera différent (parce qu'il est horodaté et que le numéro de série est différent).
3) cela dit, si les conditions évoquées dans votre message sont réunies (même bi-clef, même DN, etc.), il n'y a aucune raison pour que vous ne puissiez pas déchiffrer votre fichier (et c'est bien le souci d'ailleurs, et la raison même de la nécessité de changer le bi-clef en cas de révocation du certif pour d'autres raisons que la péremption simple).
4) utiliser de la crypto asymétrique seule pour chiffrer n'est pas la meilleure solution (à moins que votre exemple ne soit qu'un exemple, justement): la lenteur de cette méthode vous limitera assez rapidement au niveau de la taille des fichiers.
Pourriez-vous décrire les suites de commandes que vous avez utilisées pour créer vos certificats, et celles concernant le chiffrement/déchiffrement du fichier, ainsi que les messages d'erreur éventuels (parce "ça pète", c'est un peu sec ;-) ).
