Je suis en train de générer une paire de clé (public et privée) avec
GnuPG.Il me pose des questions et j'hésite sur les trois premières.
Première question:
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Comme j'y connais pas grand chose, j'ai pris la valeur par défaut (1).
C'est un bon choix?
Deuxième question:
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
J'ai envie de prendre 2048 pour une sécurité maximum.
Mais peut être que 1024 ça suffit?
Et puis plus c'est long plus c'est bon, non? ;-)
Troisième question:
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à
durée de vie limitée.
VC> Je suis en train de générer une paire de clé (public et privée) avec VC> GnuPG.Il me pose des questions et j'hésite sur les trois premières.
VC> Première question: VC> Please select what kind of key you want: VC> (1) DSA and ElGamal (default) VC> (2) DSA (sign only) VC> (5) RSA (sign only) VC> Comme j'y connais pas grand chose, j'ai pris la valeur par défaut (1). VC> C'est un bon choix?
Oui.
VC> Deuxième question: VC> DSA keypair will have 1024 bits. VC> About to generate a new ELG-E keypair. VC> minimum keysize is 768 bits VC> default keysize is 1024 bits VC> highest suggested keysize is 2048 bits VC> J'ai envie de prendre 2048 pour une sécurité maximum. VC> Mais peut être que 1024 ça suffit? VC> Et puis plus c'est long plus c'est bon, non? ;-)
En fait il y a deux clés: la clé principale qui est à 1024 bits, c'est assez, et une sous-clé qui chez moi est de 4096 bits. Ce sont donc des clés évolutives, car tout en gardant la même principale, tu peux modifier les sous-clés. C'est cela l'avantage de ce type de clés, par rapport aux RSA qui sont fixes.
VC> Troisième question: VC> Please specify how long the key should be valid. VC> 0 = key does not expire VC> <n> = key expires in n days VC> <n>w = key expires in n weeks VC> <n>m = key expires in n months VC> <n>y = key expires in n years VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à VC> durée de vie limitée.
Illimitée.
VC> Versions de mes jouets: VC> Mandrake 9.2 VC> GnuPG 1.2.3
Il y a GPG 1.2.4
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
Vincent Couquiaud <vincent.couquiaudpasde@publaposte.net.invalid> wrote:
VC> Je suis en train de générer une paire de clé (public et privée) avec
VC> GnuPG.Il me pose des questions et j'hésite sur les trois premières.
VC> Première question:
VC> Please select what kind of key you want:
VC> (1) DSA and ElGamal (default)
VC> (2) DSA (sign only)
VC> (5) RSA (sign only)
VC> Comme j'y connais pas grand chose, j'ai pris la valeur par défaut (1).
VC> C'est un bon choix?
Oui.
VC> Deuxième question:
VC> DSA keypair will have 1024 bits.
VC> About to generate a new ELG-E keypair.
VC> minimum keysize is 768 bits
VC> default keysize is 1024 bits
VC> highest suggested keysize is 2048 bits
VC> J'ai envie de prendre 2048 pour une sécurité maximum.
VC> Mais peut être que 1024 ça suffit?
VC> Et puis plus c'est long plus c'est bon, non? ;-)
En fait il y a deux clés: la clé principale qui est à 1024 bits, c'est
assez, et une sous-clé qui chez moi est de 4096 bits. Ce sont donc des clés
évolutives, car tout en gardant la même principale, tu peux modifier les
sous-clés.
C'est cela l'avantage de ce type de clés, par rapport aux RSA qui sont
fixes.
VC> Troisième question:
VC> Please specify how long the key should be valid.
VC> 0 = key does not expire
VC> <n> = key expires in n days
VC> <n>w = key expires in n weeks
VC> <n>m = key expires in n months
VC> <n>y = key expires in n years
VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à
VC> durée de vie limitée.
Illimitée.
VC> Versions de mes jouets:
VC> Mandrake 9.2
VC> GnuPG 1.2.3
Il y a GPG 1.2.4
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
VC> Je suis en train de générer une paire de clé (public et privée) avec VC> GnuPG.Il me pose des questions et j'hésite sur les trois premières.
VC> Première question: VC> Please select what kind of key you want: VC> (1) DSA and ElGamal (default) VC> (2) DSA (sign only) VC> (5) RSA (sign only) VC> Comme j'y connais pas grand chose, j'ai pris la valeur par défaut (1). VC> C'est un bon choix?
Oui.
VC> Deuxième question: VC> DSA keypair will have 1024 bits. VC> About to generate a new ELG-E keypair. VC> minimum keysize is 768 bits VC> default keysize is 1024 bits VC> highest suggested keysize is 2048 bits VC> J'ai envie de prendre 2048 pour une sécurité maximum. VC> Mais peut être que 1024 ça suffit? VC> Et puis plus c'est long plus c'est bon, non? ;-)
En fait il y a deux clés: la clé principale qui est à 1024 bits, c'est assez, et une sous-clé qui chez moi est de 4096 bits. Ce sont donc des clés évolutives, car tout en gardant la même principale, tu peux modifier les sous-clés. C'est cela l'avantage de ce type de clés, par rapport aux RSA qui sont fixes.
VC> Troisième question: VC> Please specify how long the key should be valid. VC> 0 = key does not expire VC> <n> = key expires in n days VC> <n>w = key expires in n weeks VC> <n>m = key expires in n months VC> <n>y = key expires in n years VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à VC> durée de vie limitée.
Illimitée.
VC> Versions de mes jouets: VC> Mandrake 9.2 VC> GnuPG 1.2.3
Il y a GPG 1.2.4
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Vincent Couquiaud
On 2004-04-02, Laurent Jumet wrote:
En fait il y a deux clés: la clé principale qui est à 1024 bits, c'est assez, et une sous-clé qui chez moi est de 4096 bits. Ce sont donc des clés évolutives, car tout en gardant la même principale, tu peux modifier les sous-clés. C'est cela l'avantage de ce type de clés, par rapport aux RSA qui sont fixes.
Ah oui d'accord, ça se complique là. ;-) Y a t-il une doc sur le Web qui parle de ces clés évolutives?
VC> Versions de mes jouets: VC> Mandrake 9.2 VC> GnuPG 1.2.3
Il y a GPG 1.2.4
J'ai d'ailleurs téléchargé les sources depuis quelques jours et je les ai compilé. Je me demande d'ailleurs si je peux directement écraser les binaires de ma mandrake par les nouveaux binaires...
-- E-mail: enlevez pasde, pub et .invalid.
On 2004-04-02, Laurent Jumet wrote:
En fait il y a deux clés: la clé principale qui est à 1024 bits, c'est
assez, et une sous-clé qui chez moi est de 4096 bits. Ce sont donc des clés
évolutives, car tout en gardant la même principale, tu peux modifier les
sous-clés.
C'est cela l'avantage de ce type de clés, par rapport aux RSA qui sont
fixes.
Ah oui d'accord, ça se complique là. ;-)
Y a t-il une doc sur le Web qui parle de ces clés évolutives?
VC> Versions de mes jouets:
VC> Mandrake 9.2
VC> GnuPG 1.2.3
Il y a GPG 1.2.4
J'ai d'ailleurs téléchargé les sources depuis quelques jours
et je les ai compilé. Je me demande d'ailleurs si je peux directement
écraser les binaires de ma mandrake par les nouveaux binaires...
En fait il y a deux clés: la clé principale qui est à 1024 bits, c'est assez, et une sous-clé qui chez moi est de 4096 bits. Ce sont donc des clés évolutives, car tout en gardant la même principale, tu peux modifier les sous-clés. C'est cela l'avantage de ce type de clés, par rapport aux RSA qui sont fixes.
Ah oui d'accord, ça se complique là. ;-) Y a t-il une doc sur le Web qui parle de ces clés évolutives?
VC> Versions de mes jouets: VC> Mandrake 9.2 VC> GnuPG 1.2.3
Il y a GPG 1.2.4
J'ai d'ailleurs téléchargé les sources depuis quelques jours et je les ai compilé. Je me demande d'ailleurs si je peux directement écraser les binaires de ma mandrake par les nouveaux binaires...
-- E-mail: enlevez pasde, pub et .invalid.
Vincent Couquiaud
On 2004-04-02, Laurent Jumet wrote:
VC> Troisième question: VC> Please specify how long the key should be valid. VC> 0 = key does not expire VC> <n> = key expires in n days VC> <n>w = key expires in n weeks VC> <n>m = key expires in n months VC> <n>y = key expires in n years VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à VC> durée de vie limitée.
Illimitée.
J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? J'ai lu que les certificats numériques devaient avoir une durée de vie limitée pour des questions de sécurité. Pourquoi, pour les clés, on peut choisir illimitée?
-- E-mail: enlevez pasde, pub et .invalid.
On 2004-04-02, Laurent Jumet wrote:
VC> Troisième question:
VC> Please specify how long the key should be valid.
VC> 0 = key does not expire
VC> <n> = key expires in n days
VC> <n>w = key expires in n weeks
VC> <n>m = key expires in n months
VC> <n>y = key expires in n years
VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à
VC> durée de vie limitée.
Illimitée.
J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée?
J'ai lu que les certificats numériques devaient avoir une durée de vie
limitée pour des questions de sécurité. Pourquoi, pour les clés, on peut
choisir illimitée?
VC> Troisième question: VC> Please specify how long the key should be valid. VC> 0 = key does not expire VC> <n> = key expires in n days VC> <n>w = key expires in n weeks VC> <n>m = key expires in n months VC> <n>y = key expires in n years VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée ou à VC> durée de vie limitée.
Illimitée.
J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? J'ai lu que les certificats numériques devaient avoir une durée de vie limitée pour des questions de sécurité. Pourquoi, pour les clés, on peut choisir illimitée?
-- E-mail: enlevez pasde, pub et .invalid.
Laurent Jumet
Hello !
Vincent Couquiaud wrote:
VC> On 2004-04-02, Laurent Jumet wrote:
VC> Troisième question: VC> Please specify how long the key should be valid. VC> 0 = key does not expire VC> <n> = key expires in n days VC> <n>w = key expires in n weeks VC> <n>m = key expires in n months VC> <n>y = key expires in n years VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée VC> ou à durée de vie limitée.
Illimitée.
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? VC> J'ai lu que les certificats numériques devaient avoir une durée de vie VC> limitée pour des questions de sécurité. Pourquoi, pour les clés, on VC> peut choisir illimitée?
GPG --edit_key Vincent expire
Permet de changer en tous temps la date d'expiration de ta clé, si tu le désires.
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
Vincent Couquiaud <vincent.couquiaudpasde@publaposte.net.invalid> wrote:
VC> On 2004-04-02, Laurent Jumet wrote:
VC> Troisième question:
VC> Please specify how long the key should be valid.
VC> 0 = key does not expire
VC> <n> = key expires in n days
VC> <n>w = key expires in n weeks
VC> <n>m = key expires in n months
VC> <n>y = key expires in n years
VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée
VC> ou à durée de vie limitée.
Illimitée.
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée?
VC> J'ai lu que les certificats numériques devaient avoir une durée de vie
VC> limitée pour des questions de sécurité. Pourquoi, pour les clés, on
VC> peut choisir illimitée?
GPG --edit_key Vincent
expire
Permet de changer en tous temps la date d'expiration de ta clé, si tu le
désires.
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
VC> Troisième question: VC> Please specify how long the key should be valid. VC> 0 = key does not expire VC> <n> = key expires in n days VC> <n>w = key expires in n weeks VC> <n>m = key expires in n months VC> <n>y = key expires in n years VC> Je ne sais pas si je dois choisir une clé à durée de vie illimitée VC> ou à durée de vie limitée.
Illimitée.
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? VC> J'ai lu que les certificats numériques devaient avoir une durée de vie VC> limitée pour des questions de sécurité. Pourquoi, pour les clés, on VC> peut choisir illimitée?
GPG --edit_key Vincent expire
Permet de changer en tous temps la date d'expiration de ta clé, si tu le désires.
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Vincent Couquiaud
On 2004-04-03, Laurent Jumet wrote:
Vincent Couquiaud wrote: VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? VC> J'ai lu que les certificats numériques devaient avoir une durée de vie VC> limitée pour des questions de sécurité. Pourquoi, pour les clés, on VC> peut choisir illimitée?
GPG --edit_key Vincent expire
Petite faute de frappe: c'est gpg --edit-key
Permet de changer en tous temps la date d'expiration de ta clé, si tu le désires.
Si c'est juste pour pouvoir choisir la date d'expiration aprés, je vois pas trop l'intêrét de choisir illimitée.
Bon, je sais, je suis chiant; mais j'aimerais comprendre!
-- E-mail: enlevez pasde, pub et .invalid.
On 2004-04-03, Laurent Jumet wrote:
Vincent Couquiaud <vincent.couquiaudpasde@publaposte.net.invalid> wrote:
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée?
VC> J'ai lu que les certificats numériques devaient avoir une durée de vie
VC> limitée pour des questions de sécurité. Pourquoi, pour les clés, on
VC> peut choisir illimitée?
GPG --edit_key Vincent
expire
Petite faute de frappe: c'est gpg --edit-key
Permet de changer en tous temps la date d'expiration de ta clé, si tu le
désires.
Si c'est juste pour pouvoir choisir la date d'expiration aprés, je vois
pas trop l'intêrét de choisir illimitée.
Bon, je sais, je suis chiant; mais j'aimerais comprendre!
Vincent Couquiaud wrote: VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? VC> J'ai lu que les certificats numériques devaient avoir une durée de vie VC> limitée pour des questions de sécurité. Pourquoi, pour les clés, on VC> peut choisir illimitée?
GPG --edit_key Vincent expire
Petite faute de frappe: c'est gpg --edit-key
Permet de changer en tous temps la date d'expiration de ta clé, si tu le désires.
Si c'est juste pour pouvoir choisir la date d'expiration aprés, je vois pas trop l'intêrét de choisir illimitée.
Bon, je sais, je suis chiant; mais j'aimerais comprendre!
-- E-mail: enlevez pasde, pub et .invalid.
Laurent Jumet
Hello !
Vincent Couquiaud wrote:
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? VC> J'ai lu que les certificats numériques devaient avoir une durée de VC> vie limitée pour des questions de sécurité. Pourquoi, pour les clés, VC> on peut choisir illimitée?
GPG --edit_key Vincent expire
VC> Petite faute de frappe: c'est gpg --edit-key
C'est pour voir si tu es attentif. :-)
Permet de changer en tous temps la date d'expiration de ta clé, si tu le désires.
VC> Si c'est juste pour pouvoir choisir la date d'expiration aprés, je vois VC> pas trop l'intêrét de choisir illimitée.
VC> Bon, je sais, je suis chiant; mais j'aimerais comprendre!
Une fois bien créée, ta clé va peut-être te servir vingt ans. Comme des tas de correspondants vont l'avoir, quelle drôle d'idée d'y mettre une date d'expiration. J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
Vincent Couquiaud <vincent.couquiaudpasde@publaposte.net.invalid> wrote:
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée?
VC> J'ai lu que les certificats numériques devaient avoir une durée de
VC> vie limitée pour des questions de sécurité. Pourquoi, pour les clés,
VC> on peut choisir illimitée?
GPG --edit_key Vincent
expire
VC> Petite faute de frappe: c'est gpg --edit-key
C'est pour voir si tu es attentif. :-)
Permet de changer en tous temps la date d'expiration de ta clé, si tu le
désires.
VC> Si c'est juste pour pouvoir choisir la date d'expiration aprés, je vois
VC> pas trop l'intêrét de choisir illimitée.
VC> Bon, je sais, je suis chiant; mais j'aimerais comprendre!
Une fois bien créée, ta clé va peut-être te servir vingt ans. Comme des
tas de correspondants vont l'avoir, quelle drôle d'idée d'y mettre une date
d'expiration.
J'imagine que la date d'expiration est prévue lorsque le maître de la
clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà
de telle date il est remplacé par un autre.
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
VC> J'ai oublié de demander: Pourquoi le meilleur choix c'est illimitée? VC> J'ai lu que les certificats numériques devaient avoir une durée de VC> vie limitée pour des questions de sécurité. Pourquoi, pour les clés, VC> on peut choisir illimitée?
GPG --edit_key Vincent expire
VC> Petite faute de frappe: c'est gpg --edit-key
C'est pour voir si tu es attentif. :-)
Permet de changer en tous temps la date d'expiration de ta clé, si tu le désires.
VC> Si c'est juste pour pouvoir choisir la date d'expiration aprés, je vois VC> pas trop l'intêrét de choisir illimitée.
VC> Bon, je sais, je suis chiant; mais j'aimerais comprendre!
Une fois bien créée, ta clé va peut-être te servir vingt ans. Comme des tas de correspondants vont l'avoir, quelle drôle d'idée d'y mettre une date d'expiration. J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Vincent Couquiaud
On 2004-04-03, Laurent Jumet wrote:
Une fois bien créée, ta clé va peut-être te servir vingt ans. Comme des tas de correspondants vont l'avoir, quelle drôle d'idée d'y mettre une date d'expiration. J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
Je ne suis pas encore totalement convaincu... Mais bon, je vais suivre les conseils et choisir illimitée car c'est aussi ce que j'avais envie de choisir. En tout cas, merci pour ton aide!
-- E-mail: enlevez pasde, pub et .invalid.
On 2004-04-03, Laurent Jumet wrote:
Une fois bien créée, ta clé va peut-être te servir vingt ans. Comme des
tas de correspondants vont l'avoir, quelle drôle d'idée d'y mettre une date
d'expiration.
J'imagine que la date d'expiration est prévue lorsque le maître de la
clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà
de telle date il est remplacé par un autre.
Je ne suis pas encore totalement convaincu... Mais bon, je vais suivre
les conseils et choisir illimitée car c'est aussi ce que j'avais envie
de choisir. En tout cas, merci pour ton aide!
Une fois bien créée, ta clé va peut-être te servir vingt ans. Comme des tas de correspondants vont l'avoir, quelle drôle d'idée d'y mettre une date d'expiration. J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
Je ne suis pas encore totalement convaincu... Mais bon, je vais suivre les conseils et choisir illimitée car c'est aussi ce que j'avais envie de choisir. En tout cas, merci pour ton aide!
-- E-mail: enlevez pasde, pub et .invalid.
Freyr
J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
C'est surtout intéressant quand tu fais des échanges avec des données critiques sur internet. L'idée est d'avoir un changement de clef inférieur au temps qu'il faut pour la casser. En fait tout est une questiond e risque, au plus tes données sont importantes au plus il y a des chances que beaucoup essaie de te pirater et donc de casser ton cryptage, d'où l'idée de clefs qui changent plus souvent. Dans le cas de mails perso, le risque étant faible on peut effectivement mettre une durée unfinie même si la restreindre est une bonne précaution.
J'imagine que la date d'expiration est prévue lorsque le maître de la
clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà
de telle date il est remplacé par un autre.
C'est surtout intéressant quand tu fais des échanges avec des données
critiques sur internet. L'idée est d'avoir un changement de clef
inférieur au temps qu'il faut pour la casser.
En fait tout est une questiond e risque, au plus tes données sont
importantes au plus il y a des chances que beaucoup essaie de te pirater
et donc de casser ton cryptage, d'où l'idée de clefs qui changent plus
souvent.
Dans le cas de mails perso, le risque étant faible on peut effectivement
mettre une durée unfinie même si la restreindre est une bonne précaution.
J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
C'est surtout intéressant quand tu fais des échanges avec des données critiques sur internet. L'idée est d'avoir un changement de clef inférieur au temps qu'il faut pour la casser. En fait tout est une questiond e risque, au plus tes données sont importantes au plus il y a des chances que beaucoup essaie de te pirater et donc de casser ton cryptage, d'où l'idée de clefs qui changent plus souvent. Dans le cas de mails perso, le risque étant faible on peut effectivement mettre une durée unfinie même si la restreindre est une bonne précaution.
Laurent Jumet
Hello !
Freyr wrote:
J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
F> C'est surtout intéressant quand tu fais des échanges avec des données F> critiques sur internet. L'idée est d'avoir un changement de clef F> inférieur au temps qu'il faut pour la casser. F> En fait tout est une questiond e risque, au plus tes données sont F> importantes au plus il y a des chances que beaucoup essaie de te pirater F> et donc de casser ton cryptage, d'où l'idée de clefs qui changent plus F> souvent. F> Dans le cas de mails perso, le risque étant faible on peut effectivement F> mettre une durée unfinie même si la restreindre est une bonne F> précaution.
Les renseignements que j'ai à transmettre sont tellement importants, que tous les ordinateurs du Monde travaillent en permanence pour essayer de cracker ma clé. Le secret dans mon message est celui-ci: le Coucou de Malines pèse à l'âge adulte, cinq kilos pour le coq et quatre pour la poule. Si d'aventure tu voyais ce secret quelque part, sois assez aimable de me prévenir, afin que je puisse faire expirer ma clé, et faire de la poule aux asperges de Malines.
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Hello !
Freyr <Freyr@nospam.aze> wrote:
J'imagine que la date d'expiration est prévue lorsque le maître de
la clé disparaît lui-même. Un organisme par exemple, dont on sait
qu'au-delà de telle date il est remplacé par un autre.
F> C'est surtout intéressant quand tu fais des échanges avec des données
F> critiques sur internet. L'idée est d'avoir un changement de clef
F> inférieur au temps qu'il faut pour la casser.
F> En fait tout est une questiond e risque, au plus tes données sont
F> importantes au plus il y a des chances que beaucoup essaie de te pirater
F> et donc de casser ton cryptage, d'où l'idée de clefs qui changent plus
F> souvent.
F> Dans le cas de mails perso, le risque étant faible on peut effectivement
F> mettre une durée unfinie même si la restreindre est une bonne
F> précaution.
Les renseignements que j'ai à transmettre sont tellement importants,
que tous les ordinateurs du Monde travaillent en permanence pour essayer de
cracker ma clé.
Le secret dans mon message est celui-ci: le Coucou de Malines pèse à
l'âge adulte, cinq kilos pour le coq et quatre pour la poule.
Si d'aventure tu voyais ce secret quelque part, sois assez aimable de
me prévenir, afin que je puisse faire expirer ma clé, et faire de la poule
aux asperges de Malines.
Laurent Jumet - Point de Chat, Liège, BELGIUM
KeyID: 0xCFAF704C
[Restore address to laurent.jumet for e-mail reply.]
J'imagine que la date d'expiration est prévue lorsque le maître de la clé disparaît lui-même. Un organisme par exemple, dont on sait qu'au-delà de telle date il est remplacé par un autre.
F> C'est surtout intéressant quand tu fais des échanges avec des données F> critiques sur internet. L'idée est d'avoir un changement de clef F> inférieur au temps qu'il faut pour la casser. F> En fait tout est une questiond e risque, au plus tes données sont F> importantes au plus il y a des chances que beaucoup essaie de te pirater F> et donc de casser ton cryptage, d'où l'idée de clefs qui changent plus F> souvent. F> Dans le cas de mails perso, le risque étant faible on peut effectivement F> mettre une durée unfinie même si la restreindre est une bonne F> précaution.
Les renseignements que j'ai à transmettre sont tellement importants, que tous les ordinateurs du Monde travaillent en permanence pour essayer de cracker ma clé. Le secret dans mon message est celui-ci: le Coucou de Malines pèse à l'âge adulte, cinq kilos pour le coq et quatre pour la poule. Si d'aventure tu voyais ce secret quelque part, sois assez aimable de me prévenir, afin que je puisse faire expirer ma clé, et faire de la poule aux asperges de Malines.
Laurent Jumet - Point de Chat, Liège, BELGIUM KeyID: 0xCFAF704C [Restore address to laurent.jumet for e-mail reply.]
Francois Grieu
In article <c4k8eu$hip$, Vincent Couquiaud wrote:
Première question: Please select what kind of key you want: (1) DSA and ElGamal (default) (2) DSA (sign only) (5) RSA (sign only)
Pourquoi ce GnuPG ne supporte-il pas le chiffrement RSA ? Mon PGP de base (2.63) le fait.
François Grieu
In article <c4k8eu$hip$1@news-reader2.wanadoo.fr>,
Vincent Couquiaud <vincent.couquiaudpasde@publaposte.net.invalid> wrote:
Première question:
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Pourquoi ce GnuPG ne supporte-il pas le chiffrement RSA ?
Mon PGP de base (2.63) le fait.
