Bonjour,
J'aimerais avoir quelques avis sur ceci. Trouvez-vous acceptable qu'à
chaque cryptogramme il y ait une partie chiffré d'ajoutée ayant un total de
46 octets pour les infos suivantes:
- date de chiffrement,
- taille originale des données chiffrées,
- indicateur permettant un arrêt ou non pour:
* l'accusé de réception,
* la validité de la clef personnelle de l'utilisateur,
- un octet indiquant si oui ou non on intègre la fiche d'info qui peut
contenir les nom, adresse, photo, etc.),
- hash de 8 octets aidant à vérifier que le début des données du chiffré
correspond à l'original,
- hash de 8 octets aidant à vérifier que la fin des données du chiffré
correspond à l'original,
- hash de 8 octets aidant à vérifier que la clef personnelle correspond
(avant de poursuivre le déchiffrement),
- code de 8 octets à transmettre à l'expéditeur lui certifiant que
l'utilisateur a bien reçu le chiffré (afin d'envoyer à cet utilisateur une
clef spéciale et unique permettant de poursuivre le déchiffrement),
- code généré étant l'accusé de réception à fournir à l'expéditeur pour que
celui-ci lui envoie une clef spéciale permettant la suite du déchiffrement
(clef de l'accusé de réception étant différente des 2 clefs de sessions
servant au déchiffrement du cryptogramme entier).
À noter aussi que les 2 clefs de session (générées à chaque
chiffrement) font partie de ce bloc détaillé ci-dessus. Ces 2 clefs ont un
minimum de 128 bits chacune. La clef personnelle est utilisée pour le
chiffrement de ce bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple
cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion
qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les
disques dur d'aujourd'hui et avec la rapidité des ordinateurs d'aujourd'hui
que 46 octets (plus les 2 clefs de sessions) seraient une bagatelle à ne pas
tenir compte. Qu'en pensez-vous?
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
Raymond H.
Je rectifie:
Bonjour, J'aimerais avoir quelques avis sur ceci. Trouvez-vous acceptable d'ajouter à chaque cryptogramme une partie chiffrée ayant un total de 46 octets pour les infos suivantes:
- date de chiffrement, - taille originale des données chiffrées, - indicateur permettant un arrêt ou non pour: * la validité de la clef de l'accusé de réception, * la validité de la clef personnelle de l'utilisateur, - un octet indiquant si oui ou non on intègre la fiche d'info qui peut contenir: nom, adresse, photo, etc., - hash de 8 octets certifiant que le début des données du chiffré correspond à l'original, - hash de 8 octets certifiant que la fin des données du chiffré correspond à l'original, - hash de 8 octets certifiant que la clef personnelle est exacte (avant de poursuivre le déchiffrement), - code de 8 octets (pour l'accusé de réception) à transmettre à l'expéditeur lui certifiant que l'utilisateur a bien reçu le chiffré (afin que l'expéditeur envoie à cet utilisateur une clef spéciale et unique permettant de poursuivre le déchiffrement); la clef de l'accusé de réception est différente des 2 clefs de sessions servant au déchiffrement du cryptogramme entier.
À noter aussi que les 2 clefs de session (générées à chaque chiffrement) font partie de ce bloc détaillé ci-dessus. Ces 2 clefs ont un minimum de 128 bits chacune (même taille que la clef personnelle de l'utilisateur). La clef personnelle est utilisée pour le chiffrement de ce bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les disques dur d'aujourd'hui et avec la rapidité des ordinateurs d'aujourd'hui que 46 octets (plus les 2 clefs de sessions) seraient une bagatelle à ne pas tenir compte. Qu'en pensez-vous?
Raymond H.
Je rectifie:
Bonjour,
J'aimerais avoir quelques avis sur ceci. Trouvez-vous acceptable
d'ajouter à chaque cryptogramme une partie chiffrée ayant un total de 46
octets pour les infos suivantes:
- date de chiffrement,
- taille originale des données chiffrées,
- indicateur permettant un arrêt ou non pour:
* la validité de la clef de l'accusé de réception,
* la validité de la clef personnelle de l'utilisateur,
- un octet indiquant si oui ou non on intègre la fiche d'info qui peut
contenir: nom, adresse, photo, etc.,
- hash de 8 octets certifiant que le début des données du chiffré correspond
à l'original,
- hash de 8 octets certifiant que la fin des données du chiffré correspond à
l'original,
- hash de 8 octets certifiant que la clef personnelle est exacte (avant de
poursuivre le déchiffrement),
- code de 8 octets (pour l'accusé de réception) à transmettre à l'expéditeur
lui certifiant que l'utilisateur a bien reçu le chiffré (afin que
l'expéditeur envoie à cet utilisateur une clef spéciale et unique permettant
de poursuivre le déchiffrement); la clef de l'accusé de réception est
différente des 2 clefs de sessions servant au déchiffrement du cryptogramme
entier.
À noter aussi que les 2 clefs de session (générées à chaque
chiffrement) font partie de ce bloc détaillé ci-dessus. Ces 2 clefs ont un
minimum de 128 bits chacune (même taille que la clef personnelle de
l'utilisateur). La clef personnelle est utilisée pour le chiffrement de ce
bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple
cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion
qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les
disques dur d'aujourd'hui et avec la rapidité des ordinateurs d'aujourd'hui
que 46 octets (plus les 2 clefs de sessions) seraient une bagatelle à ne pas
tenir compte. Qu'en pensez-vous?
Bonjour, J'aimerais avoir quelques avis sur ceci. Trouvez-vous acceptable d'ajouter à chaque cryptogramme une partie chiffrée ayant un total de 46 octets pour les infos suivantes:
- date de chiffrement, - taille originale des données chiffrées, - indicateur permettant un arrêt ou non pour: * la validité de la clef de l'accusé de réception, * la validité de la clef personnelle de l'utilisateur, - un octet indiquant si oui ou non on intègre la fiche d'info qui peut contenir: nom, adresse, photo, etc., - hash de 8 octets certifiant que le début des données du chiffré correspond à l'original, - hash de 8 octets certifiant que la fin des données du chiffré correspond à l'original, - hash de 8 octets certifiant que la clef personnelle est exacte (avant de poursuivre le déchiffrement), - code de 8 octets (pour l'accusé de réception) à transmettre à l'expéditeur lui certifiant que l'utilisateur a bien reçu le chiffré (afin que l'expéditeur envoie à cet utilisateur une clef spéciale et unique permettant de poursuivre le déchiffrement); la clef de l'accusé de réception est différente des 2 clefs de sessions servant au déchiffrement du cryptogramme entier.
À noter aussi que les 2 clefs de session (générées à chaque chiffrement) font partie de ce bloc détaillé ci-dessus. Ces 2 clefs ont un minimum de 128 bits chacune (même taille que la clef personnelle de l'utilisateur). La clef personnelle est utilisée pour le chiffrement de ce bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les disques dur d'aujourd'hui et avec la rapidité des ordinateurs d'aujourd'hui que 46 octets (plus les 2 clefs de sessions) seraient une bagatelle à ne pas tenir compte. Qu'en pensez-vous?
Raymond H.
Raymond H.
À noter aussi que les 2 clefs de session (générées à chaque chiffrement) font partie de ce bloc détaillé ci-dessus.
Je précise: J'aurais dû écrire ceci: "... les 2 clefs de session finales...". Car ce sont les 2 clefs de session initiales qui sont créées aléatoirement. Ces 2 clefs initiales sont prolongées au fur et à mesure du chiffrement en sorte que seulement la fin (les 2 clefs finales) de ces 2 clefs de session complètes sont concervées pour être chiffrées puis joint à la fin du cryptogramme.
r.h.
Ces 2 clefs ont un minimum de 128 bits chacune (même taille que la clef personnelle de l'utilisateur). La clef personnelle est utilisée pour le chiffrement de ce bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les disques dur d'aujourd'hui et avec la rapidité des ordinateurs d'aujourd'hui que 46 octets (plus les 2 clefs de sessions) seraient une bagatelle à ne pas tenir compte. Qu'en pensez-vous?
Raymond H.
À noter aussi que les 2 clefs de session (générées à chaque
chiffrement) font partie de ce bloc détaillé ci-dessus.
Je précise:
J'aurais dû écrire ceci: "... les 2 clefs de session finales...".
Car ce sont les 2 clefs de session initiales qui sont créées aléatoirement.
Ces 2 clefs initiales sont prolongées au fur et à mesure du chiffrement en
sorte que seulement la fin (les 2 clefs finales) de ces 2 clefs de session
complètes sont concervées pour être chiffrées puis joint à la fin du
cryptogramme.
r.h.
Ces 2 clefs ont un
minimum de 128 bits chacune (même taille que la clef personnelle de
l'utilisateur). La clef personnelle est utilisée pour le chiffrement de
ce bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple
cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion
qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les
disques dur d'aujourd'hui et avec la rapidité des ordinateurs
d'aujourd'hui que 46 octets (plus les 2 clefs de sessions) seraient une
bagatelle à ne pas tenir compte. Qu'en pensez-vous?
À noter aussi que les 2 clefs de session (générées à chaque chiffrement) font partie de ce bloc détaillé ci-dessus.
Je précise: J'aurais dû écrire ceci: "... les 2 clefs de session finales...". Car ce sont les 2 clefs de session initiales qui sont créées aléatoirement. Ces 2 clefs initiales sont prolongées au fur et à mesure du chiffrement en sorte que seulement la fin (les 2 clefs finales) de ces 2 clefs de session complètes sont concervées pour être chiffrées puis joint à la fin du cryptogramme.
r.h.
Ces 2 clefs ont un minimum de 128 bits chacune (même taille que la clef personnelle de l'utilisateur). La clef personnelle est utilisée pour le chiffrement de ce bloc qui est ajouté à la fin du cryptogramme.
Je n'aimais pas trop le fait que 46 octets soient ajoutés à un simple cryptogramme de 3 mots par exemple, mais je suis arrivé à la conclusion qu'on n'est plus au temps du XT (ordinateurs des années 70) et qu'avec les disques dur d'aujourd'hui et avec la rapidité des ordinateurs d'aujourd'hui que 46 octets (plus les 2 clefs de sessions) seraient une bagatelle à ne pas tenir compte. Qu'en pensez-vous?
Raymond H.
Phil l'ancien
Raymond H.
Ca me semble aussi sans conséquence, puisque la taille des données ajoutées est généralement negligeable devant la taille du fichier chiffré.
Ca rejoint une autre préoccupation que j'ai.
Il me semble que si quelqu'un dispose de plusieurs fichiers chiffrés et des mêmes fichiers en clair, ça l'aide beaucoup à "briser le code" et à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent, les documents d'une société contiennent des zones totalement prévisibles, et toujours identiques (par exemple parce que les documents respectent une charte graphique, ou une norme, ou parce qu'il y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Phil l'ancien-
Raymond H.
Ca me semble aussi sans conséquence, puisque la
taille des données ajoutées est généralement negligeable
devant la taille du fichier chiffré.
Ca rejoint une autre préoccupation que j'ai.
Il me semble que si quelqu'un dispose de plusieurs
fichiers chiffrés et des mêmes fichiers en clair,
ça l'aide beaucoup à "briser le code" et
à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent,
les documents d'une société contiennent des
zones totalement prévisibles, et toujours identiques
(par exemple parce que les documents respectent
une charte graphique, ou une norme, ou parce qu'il
y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Ca me semble aussi sans conséquence, puisque la taille des données ajoutées est généralement negligeable devant la taille du fichier chiffré.
Ca rejoint une autre préoccupation que j'ai.
Il me semble que si quelqu'un dispose de plusieurs fichiers chiffrés et des mêmes fichiers en clair, ça l'aide beaucoup à "briser le code" et à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent, les documents d'une société contiennent des zones totalement prévisibles, et toujours identiques (par exemple parce que les documents respectent une charte graphique, ou une norme, ou parce qu'il y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Phil l'ancien-
Raymond H.
Bonsoir, "Phil l'ancien" a écrit dans le message de news: 4410c481$0$18313$
Raymond H.
Ca me semble aussi sans conséquence, puisque la taille des données ajoutées est généralement negligeable devant la taille du fichier chiffré.
Ca rejoint une autre préoccupation que j'ai.
Il me semble que si quelqu'un dispose de plusieurs fichiers chiffrés et des mêmes fichiers en clair, ça l'aide beaucoup à "briser le code" et à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent, les documents d'une société contiennent des zones totalement prévisibles, et toujours identiques (par exemple parce que les documents respectent une charte graphique, ou une norme, ou parce qu'il y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Non, car le clair est chiffré via 2 clef de session qui ne sont jamais les mêmes. Mais dans un avenir rapproché je veux vous présenter sur pages Internet l'algo utilisé. Merci pour vos commentaires :) Raymond H.
Bonsoir,
"Phil l'ancien" <nicetry@noway.com> a écrit dans le message de news:
4410c481$0$18313$8fcfb975@news.wanadoo.fr...
Raymond H.
Ca me semble aussi sans conséquence, puisque la
taille des données ajoutées est généralement negligeable
devant la taille du fichier chiffré.
Ca rejoint une autre préoccupation que j'ai.
Il me semble que si quelqu'un dispose de plusieurs
fichiers chiffrés et des mêmes fichiers en clair,
ça l'aide beaucoup à "briser le code" et
à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent,
les documents d'une société contiennent des
zones totalement prévisibles, et toujours identiques
(par exemple parce que les documents respectent
une charte graphique, ou une norme, ou parce qu'il
y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Non, car le clair est chiffré via 2 clef de session qui ne sont jamais les
mêmes. Mais dans un avenir rapproché je veux vous présenter sur pages
Internet l'algo utilisé.
Merci pour vos commentaires :)
Raymond H.
Bonsoir, "Phil l'ancien" a écrit dans le message de news: 4410c481$0$18313$
Raymond H.
Ca me semble aussi sans conséquence, puisque la taille des données ajoutées est généralement negligeable devant la taille du fichier chiffré.
Ca rejoint une autre préoccupation que j'ai.
Il me semble que si quelqu'un dispose de plusieurs fichiers chiffrés et des mêmes fichiers en clair, ça l'aide beaucoup à "briser le code" et à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent, les documents d'une société contiennent des zones totalement prévisibles, et toujours identiques (par exemple parce que les documents respectent une charte graphique, ou une norme, ou parce qu'il y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Non, car le clair est chiffré via 2 clef de session qui ne sont jamais les mêmes. Mais dans un avenir rapproché je veux vous présenter sur pages Internet l'algo utilisé. Merci pour vos commentaires :) Raymond H.
Phil l'ancien
Raymond H.
Phil l'ancien
Raymond H.
Il me semble que si quelqu'un dispose de plusieurs fichiers chiffrés et des mêmes fichiers en clair, ça l'aide beaucoup à "briser le code" et à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent, les documents d'une société contiennent des zones totalement prévisibles, et toujours identiques (par exemple parce que les documents respectent une charte graphique, ou une norme, ou parce qu'il y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Non, car le clair est chiffré via 2 clef de session qui ne sont jamais les mêmes. Mais dans un avenir rapproché je veux vous présenter sur pages Internet l'algo utilisé. Merci pour vos commentaires :) Raymond H.
De quoi vous parlez, là ?
Ma question est générale, et ne porte pas sur une technique de chiffrement particulière ou une autre. Et surement pas spécialement sur la votre.
"Merci pour vos commentaires"
Mes commentaires sur quoi ? Ca va les chevilles, pas trop gonflées ?
Phil l'ancien-
Raymond H.
Phil l'ancien
Raymond H.
Il me semble que si quelqu'un dispose de plusieurs
fichiers chiffrés et des mêmes fichiers en clair,
ça l'aide beaucoup à "briser le code" et
à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent,
les documents d'une société contiennent des
zones totalement prévisibles, et toujours identiques
(par exemple parce que les documents respectent
une charte graphique, ou une norme, ou parce qu'il
y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Non, car le clair est chiffré via 2 clef de session qui ne sont jamais les
mêmes. Mais dans un avenir rapproché je veux vous présenter sur pages
Internet l'algo utilisé.
Merci pour vos commentaires :)
Raymond H.
De quoi vous parlez, là ?
Ma question est générale, et ne porte pas sur une
technique de chiffrement particulière ou une autre.
Et surement pas spécialement sur la votre.
"Merci pour vos commentaires"
Mes commentaires sur quoi ?
Ca va les chevilles, pas trop gonflées ?
Il me semble que si quelqu'un dispose de plusieurs fichiers chiffrés et des mêmes fichiers en clair, ça l'aide beaucoup à "briser le code" et à déchiffrer d'autres fichiers.
C'est bien correct ?
Ca semble introduire un problème : assez souvent, les documents d'une société contiennent des zones totalement prévisibles, et toujours identiques (par exemple parce que les documents respectent une charte graphique, ou une norme, ou parce qu'il y a toujours "copyright société machin".)
Est-ce que n'affaiblit pas la sécurité du chiffrement ?
Non, car le clair est chiffré via 2 clef de session qui ne sont jamais les mêmes. Mais dans un avenir rapproché je veux vous présenter sur pages Internet l'algo utilisé. Merci pour vos commentaires :) Raymond H.
De quoi vous parlez, là ?
Ma question est générale, et ne porte pas sur une technique de chiffrement particulière ou une autre. Et surement pas spécialement sur la votre.
"Merci pour vos commentaires"
Mes commentaires sur quoi ? Ca va les chevilles, pas trop gonflées ?
