OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko.
Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM.....
Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko ....
alors que je le jète !
En clair : impossible de trouver les premiers octets.
Pour faire simple : je ne vais jamais donner la signature PK : les 2
premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
Plus complexe : au lieu de commencer à attaquer la clé au même endroit, je
peux commencer au milieu :
Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER....
Demain je commence par IOPAZERTYU....
Ce qui motive le changement de départ : un calcul sur la taille du fichier,
sa date, son nom... etc
Je scrute le nom.... et je sais où ma clé commence.
J'ai donc réalisé une clé jetable.... sans avoir à la donner initialement.
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
shen
On Sun, 14 Nov 2004 23:45:29 +0100 wrote:
OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko. Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM..... Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko .... alors que je le jète !
En clair : impossible de trouver les premiers octets.
Pour faire simple : je ne vais jamais donner la signature PK : les 2 premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
Plus complexe : au lieu de commencer à attaquer la clé au même end roit, je peux commencer au milieu : Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER.... Demain je commence par IOPAZERTYU.... Ce qui motive le changement de départ : un calcul sur la taille du fichier, sa date, son nom... etc Je scrute le nom.... et je sais où ma clé commence. J'ai donc réalisé une clé jetable.... sans avoir à la donner init ialement.
Que pensez vous de ces 2 méthodes ?
Qu'elles ne respectent pas le premier principe fondamental de Kerchoffs sur la cryptographie. A partir du moment où la technique de chiffrement repose sur le secret de celle-ci, elle est considérée mauvaise et vulnérable.
-- shen "You know what, I'm happy..." Droopy
On Sun, 14 Nov 2004 23:45:29 +0100
<huchette.andre@numericable.fr> wrote:
OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko.
Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM.....
Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko ....
alors que je le jète !
En clair : impossible de trouver les premiers octets.
Pour faire simple : je ne vais jamais donner la signature PK : les 2
premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
Plus complexe : au lieu de commencer à attaquer la clé au même end roit,
je peux commencer au milieu :
Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER....
Demain je commence par IOPAZERTYU....
Ce qui motive le changement de départ : un calcul sur la taille du
fichier, sa date, son nom... etc
Je scrute le nom.... et je sais où ma clé commence.
J'ai donc réalisé une clé jetable.... sans avoir à la donner init ialement.
Que pensez vous de ces 2 méthodes ?
Qu'elles ne respectent pas le premier principe fondamental de Kerchoffs sur
la cryptographie.
A partir du moment où la technique de chiffrement repose sur le secret de
celle-ci, elle est considérée mauvaise et vulnérable.
OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko. Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM..... Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko .... alors que je le jète !
En clair : impossible de trouver les premiers octets.
Pour faire simple : je ne vais jamais donner la signature PK : les 2 premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
Plus complexe : au lieu de commencer à attaquer la clé au même end roit, je peux commencer au milieu : Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER.... Demain je commence par IOPAZERTYU.... Ce qui motive le changement de départ : un calcul sur la taille du fichier, sa date, son nom... etc Je scrute le nom.... et je sais où ma clé commence. J'ai donc réalisé une clé jetable.... sans avoir à la donner init ialement.
Que pensez vous de ces 2 méthodes ?
Qu'elles ne respectent pas le premier principe fondamental de Kerchoffs sur la cryptographie. A partir du moment où la technique de chiffrement repose sur le secret de celle-ci, elle est considérée mauvaise et vulnérable.
-- shen "You know what, I'm happy..." Droopy
chaton
wrote in message news:<4197e033$0$285$...
OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
entre autres.
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko. Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM..... Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko .... alors que je le jète !
En clair : impossible de trouver les premiers octets.
meme si les premiers octets sont difficile a trouver (et pas impossible), cela ne change pas le probleme lie au fait que xor dispose de proprietes qui aident l'analyse sur le reste du message. ajouter des octets aleatoires au debut du message va eventuellement retarder l'analyse de quelques secondes, le temps de se rendre compte que seuls les n premiers octets changent sur un meme message. il existe des modes de chiffrement qui utilisent des octets aleatoires, mais ceux ci sont utilises pour alterer l'ensemble du message.
la securite se fait par la robustesse de la methode, non pas par les methodes permettant d'en camoufler les faiblesses.
Pour faire simple : je ne vais jamais donner la signature PK : les 2 premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
l'entete se retrouvera decale de n octets, mais cela ne fera pas la moindre difference pour l'analyste qui ne se souciera pas du format du fichier clair mais des donnees qu'il contient.
Plus complexe : au lieu de commencer à attaquer la clé au même endroit, je peux commencer au milieu : Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER.... Demain je commence par IOPAZERTYU.... Ce qui motive le changement de départ : un calcul sur la taille du fichier, sa date, son nom... etc Je scrute le nom.... et je sais où ma clé commence.
J'ai donc réalisé une clé jetable.... sans avoir à la donner initialement.
L'analyste scrute le nom et sait aussi ou la clef commence, la encore cela va retarder _legerement_ le temps que mettera l'analyste a recuperer les infos dont il a besoin, mais ne l'empechera absolument pas de faire son travail.
Que pensez vous de ces 2 méthodes ?
xor est un _operateur_ et pas une methode de chiffrement, peu importe la facon dont tu t'en servira, si la clef n'est pas un masque jetable (les conditions sont un peu plus complexes que celle que tu decris), ses proprietes feront que l'analyse sera _beaucoup_ plus simple qu'avec une _vraie_ methode de chiffrement.
<huchette.andre@numericable.fr> wrote in message news:<4197e033$0$285$a3f2974a@nnrp1.numericable.fr>...
OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
entre autres.
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko.
Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM.....
Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko ....
alors que je le jète !
En clair : impossible de trouver les premiers octets.
meme si les premiers octets sont difficile a trouver (et pas impossible), cela
ne change pas le probleme lie au fait que xor dispose de proprietes qui aident
l'analyse sur le reste du message. ajouter des octets aleatoires au debut du
message va eventuellement retarder l'analyse de quelques secondes, le temps de
se rendre compte que seuls les n premiers octets changent sur un meme message.
il existe des modes de chiffrement qui utilisent des octets aleatoires, mais
ceux ci sont utilises pour alterer l'ensemble du message.
la securite se fait par la robustesse de la methode, non pas par les methodes
permettant d'en camoufler les faiblesses.
Pour faire simple : je ne vais jamais donner la signature PK : les 2
premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
l'entete se retrouvera decale de n octets, mais cela ne fera pas la moindre
difference pour l'analyste qui ne se souciera pas du format du fichier clair
mais des donnees qu'il contient.
Plus complexe : au lieu de commencer à attaquer la clé au même endroit, je
peux commencer au milieu :
Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER....
Demain je commence par IOPAZERTYU....
Ce qui motive le changement de départ : un calcul sur la taille du fichier,
sa date, son nom... etc
Je scrute le nom.... et je sais où ma clé commence.
J'ai donc réalisé une clé jetable.... sans avoir à la donner initialement.
L'analyste scrute le nom et sait aussi ou la clef commence, la encore cela va
retarder _legerement_ le temps que mettera l'analyste a recuperer les infos
dont il a besoin, mais ne l'empechera absolument pas de faire son travail.
Que pensez vous de ces 2 méthodes ?
xor est un _operateur_ et pas une methode de chiffrement, peu importe la facon
dont tu t'en servira, si la clef n'est pas un masque jetable (les conditions
sont un peu plus complexes que celle que tu decris), ses proprietes feront que
l'analyse sera _beaucoup_ plus simple qu'avec une _vraie_ methode de
chiffrement.
OK : plus j'ai de messages, plus j'ai de chance de me faire décoder....
entre autres.
Et si maintenant, je crée une entête TOTALEMENT INUTILE.... disons 1 Ko. Inutile et aléatoire : le contenu d'un fichier ZIP, EXE, COM..... Le décodeur indélicat s'attachera à trouver un sens à mon premier Ko .... alors que je le jète !
En clair : impossible de trouver les premiers octets.
meme si les premiers octets sont difficile a trouver (et pas impossible), cela ne change pas le probleme lie au fait que xor dispose de proprietes qui aident l'analyse sur le reste du message. ajouter des octets aleatoires au debut du message va eventuellement retarder l'analyse de quelques secondes, le temps de se rendre compte que seuls les n premiers octets changent sur un meme message. il existe des modes de chiffrement qui utilisent des octets aleatoires, mais ceux ci sont utilises pour alterer l'ensemble du message.
la securite se fait par la robustesse de la methode, non pas par les methodes permettant d'en camoufler les faiblesses.
Pour faire simple : je ne vais jamais donner la signature PK : les 2 premiers octets d'un fichier ZIP ; ou MZ d'un EXE.
l'entete se retrouvera decale de n octets, mais cela ne fera pas la moindre difference pour l'analyste qui ne se souciera pas du format du fichier clair mais des donnees qu'il contient.
Plus complexe : au lieu de commencer à attaquer la clé au même endroit, je peux commencer au milieu : Exemple ma cle est AZERTYUIOP..... aujourd'hui le commence par AZER.... Demain je commence par IOPAZERTYU.... Ce qui motive le changement de départ : un calcul sur la taille du fichier, sa date, son nom... etc Je scrute le nom.... et je sais où ma clé commence.
J'ai donc réalisé une clé jetable.... sans avoir à la donner initialement.
L'analyste scrute le nom et sait aussi ou la clef commence, la encore cela va retarder _legerement_ le temps que mettera l'analyste a recuperer les infos dont il a besoin, mais ne l'empechera absolument pas de faire son travail.
Que pensez vous de ces 2 méthodes ?
xor est un _operateur_ et pas une methode de chiffrement, peu importe la facon dont tu t'en servira, si la clef n'est pas un masque jetable (les conditions sont un peu plus complexes que celle que tu decris), ses proprietes feront que l'analyse sera _beaucoup_ plus simple qu'avec une _vraie_ methode de chiffrement.
