Je viens de trouver une solution pour tenter d'éliminer la
possibilité
d'une attaque à clair connu (donc, via un en-tête connu à cause de
l'extension du nom du fichier).
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Avant de chiffrer avec un xor, je fais une permutation du clair par
groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e
caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi
les
10 choix disponibles de permutation pour les 8 caractères qui précèdent
ce
9e caractère. Donc, le choix de permutation est imprévisible. Ensuite
seulement, on chiffre.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
Après avoir permuter l'ensemble du clair, on crée la clef puis on
chiffre le clair via un xor entre la clef de session et le clair. Ainsi
en
est-il pour empêcher une attaque à clair connu.
On mathématise un poil :
M le Message clair.
C le chiffré
K la clé
b() fonction de brouillage
c() fonction de chiffrement
Le brouillage préalable se traduit par :
b(M)
Le chiffrement du brouillé se traduit par :
C = f( b(M),K )
Par hypothèse, le brouillage est réversible. Il existe donc une fonction
réciproque que j'appele b_1 (lire "bé moins zun"). De même pour la
fonction de déchiffrement f_1.
Ainsi : M = b_1( f_1(C,K) ) pour le déchiffrement.
J'ai des chiffrés et leurs clairs.
Il va donc falloir passer le
brouillage qui n'est un chiffrement par substitution à clé unique. Avant
on avait, en gros, une superposition de deux chiffrements à clés,
maintenant il n'y en plus qu'un. Pas sûr que cela soit mieux.
Dans une hypothèse où la clé K est le seul secret inconnu, le brouillage
ne sert plus à rien puisque la fonction est disponible dans le
code source.
De ce fait, je calcule b(M) que je nomme M' ("ème prime"). Le problème
devient : C = f(M',K). Et on est ramené à la cryptanalyse "classique".
La sécurité du brouillage repose donc sur l'obscurité : on n'est pas
censé disposer du code source du chiffrement. Pas bon.
Je viens de trouver une solution pour tenter d'éliminer la
possibilité
d'une attaque à clair connu (donc, via un en-tête connu à cause de
l'extension du nom du fichier).
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Avant de chiffrer avec un xor, je fais une permutation du clair par
groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e
caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi
les
10 choix disponibles de permutation pour les 8 caractères qui précèdent
ce
9e caractère. Donc, le choix de permutation est imprévisible. Ensuite
seulement, on chiffre.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
Après avoir permuter l'ensemble du clair, on crée la clef puis on
chiffre le clair via un xor entre la clef de session et le clair. Ainsi
en
est-il pour empêcher une attaque à clair connu.
On mathématise un poil :
M le Message clair.
C le chiffré
K la clé
b() fonction de brouillage
c() fonction de chiffrement
Le brouillage préalable se traduit par :
b(M)
Le chiffrement du brouillé se traduit par :
C = f( b(M),K )
Par hypothèse, le brouillage est réversible. Il existe donc une fonction
réciproque que j'appele b_1 (lire "bé moins zun"). De même pour la
fonction de déchiffrement f_1.
Ainsi : M = b_1( f_1(C,K) ) pour le déchiffrement.
J'ai des chiffrés et leurs clairs.
Il va donc falloir passer le
brouillage qui n'est un chiffrement par substitution à clé unique. Avant
on avait, en gros, une superposition de deux chiffrements à clés,
maintenant il n'y en plus qu'un. Pas sûr que cela soit mieux.
Dans une hypothèse où la clé K est le seul secret inconnu, le brouillage
ne sert plus à rien puisque la fonction est disponible dans le
code source.
De ce fait, je calcule b(M) que je nomme M' ("ème prime"). Le problème
devient : C = f(M',K). Et on est ramené à la cryptanalyse "classique".
La sécurité du brouillage repose donc sur l'obscurité : on n'est pas
censé disposer du code source du chiffrement. Pas bon.
Je viens de trouver une solution pour tenter d'éliminer la
possibilité
d'une attaque à clair connu (donc, via un en-tête connu à cause de
l'extension du nom du fichier).
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Avant de chiffrer avec un xor, je fais une permutation du clair par
groupe de 8 octets. Le chiffre de droite dans la valeur ascii du 9e
caractère (de 0 à 9) indique la permutation qui doit être utilisée parmi
les
10 choix disponibles de permutation pour les 8 caractères qui précèdent
ce
9e caractère. Donc, le choix de permutation est imprévisible. Ensuite
seulement, on chiffre.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
Après avoir permuter l'ensemble du clair, on crée la clef puis on
chiffre le clair via un xor entre la clef de session et le clair. Ainsi
en
est-il pour empêcher une attaque à clair connu.
On mathématise un poil :
M le Message clair.
C le chiffré
K la clé
b() fonction de brouillage
c() fonction de chiffrement
Le brouillage préalable se traduit par :
b(M)
Le chiffrement du brouillé se traduit par :
C = f( b(M),K )
Par hypothèse, le brouillage est réversible. Il existe donc une fonction
réciproque que j'appele b_1 (lire "bé moins zun"). De même pour la
fonction de déchiffrement f_1.
Ainsi : M = b_1( f_1(C,K) ) pour le déchiffrement.
J'ai des chiffrés et leurs clairs.
Il va donc falloir passer le
brouillage qui n'est un chiffrement par substitution à clé unique. Avant
on avait, en gros, une superposition de deux chiffrements à clés,
maintenant il n'y en plus qu'un. Pas sûr que cela soit mieux.
Dans une hypothèse où la clé K est le seul secret inconnu, le brouillage
ne sert plus à rien puisque la fonction est disponible dans le
code source.
De ce fait, je calcule b(M) que je nomme M' ("ème prime"). Le problème
devient : C = f(M',K). Et on est ramené à la cryptanalyse "classique".
La sécurité du brouillage repose donc sur l'obscurité : on n'est pas
censé disposer du code source du chiffrement. Pas bon.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris. Le brouillage dépend de
la clef de session dans le sens que le clair brouillé est par la suite
chiffré de la même façon que mentionnée dans mes derniers messages. Même
chose pour la clef de session, on ne conserve que la clef de session
finale.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris. Le brouillage dépend de
la clef de session dans le sens que le clair brouillé est par la suite
chiffré de la même façon que mentionnée dans mes derniers messages. Même
chose pour la clef de session, on ne conserve que la clef de session
finale.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris. Le brouillage dépend de
la clef de session dans le sens que le clair brouillé est par la suite
chiffré de la même façon que mentionnée dans mes derniers messages. Même
chose pour la clef de session, on ne conserve que la clef de session
finale.
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Ici, je me limitais à parler de l'attaque mentionnée dans mes derniers
messages: celui où on peut savoir quelques caractères d'un en-tête ayant
toujours ou presque les même caractères pour identifier le fichier.
Exemple, l'extension jpeg contient un en-tête propre à lui et si l'on
connaît l'extension on connaît donc cet en-tête et on peut deviner certains
caractères du chiffré. Mais, sûrement vous saviez que c'est de cela dont je
parlais.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris.
...Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
...
Faudrait relire plus attentivement mon explication qui est quand même
assez clair à cause de l'exemple donné.
J'ai des chiffrés et leurs clairs.
Je pense que vous n'avez aucune chance de débrouiller le clair puisqu'il
faudrait auparavant déchiffrer le chiffré auparavant.
...
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Ici, je me limitais à parler de l'attaque mentionnée dans mes derniers
messages: celui où on peut savoir quelques caractères d'un en-tête ayant
toujours ou presque les même caractères pour identifier le fichier.
Exemple, l'extension jpeg contient un en-tête propre à lui et si l'on
connaît l'extension on connaît donc cet en-tête et on peut deviner certains
caractères du chiffré. Mais, sûrement vous saviez que c'est de cela dont je
parlais.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris.
...
Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
...
Faudrait relire plus attentivement mon explication qui est quand même
assez clair à cause de l'exemple donné.
J'ai des chiffrés et leurs clairs.
Je pense que vous n'avez aucune chance de débrouiller le clair puisqu'il
faudrait auparavant déchiffrer le chiffré auparavant.
...
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Ici, je me limitais à parler de l'attaque mentionnée dans mes derniers
messages: celui où on peut savoir quelques caractères d'un en-tête ayant
toujours ou presque les même caractères pour identifier le fichier.
Exemple, l'extension jpeg contient un en-tête propre à lui et si l'on
connaît l'extension on connaît donc cet en-tête et on peut deviner certains
caractères du chiffré. Mais, sûrement vous saviez que c'est de cela dont je
parlais.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris.
...Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
...
Faudrait relire plus attentivement mon explication qui est quand même
assez clair à cause de l'exemple donné.
J'ai des chiffrés et leurs clairs.
Je pense que vous n'avez aucune chance de débrouiller le clair puisqu'il
faudrait auparavant déchiffrer le chiffré auparavant.
...
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Ici, je me limitais à parler de l'attaque mentionnée dans mes
derniers
messages: celui où on peut savoir quelques caractères d'un en-tête ayant
toujours ou presque les même caractères pour identifier le fichier.
Exemple, l'extension jpeg contient un en-tête propre à lui et si l'on
connaît l'extension on connaît donc cet en-tête et on peut deviner
certains
caractères du chiffré. Mais, sûrement vous saviez que c'est de cela dont
je
parlais.
Non. Je ne devine pas. Je suis absolument dépourvu de cette capacité. En
cas de doute, je préfère poser la question. Ta réponse faisait
naturellement partie des possibles.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris.
...Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
...
Faudrait relire plus attentivement mon explication qui est quand même
assez clair à cause de l'exemple donné.
Il serait utile d'adopter un autre ton envers quelqu'un qui t'aide
bénévolement et qui met publiquement ses preuves à disposition.
J'ai des chiffrés et leurs clairs.
Je pense que vous n'avez aucune chance de débrouiller le clair
puisqu'il
faudrait auparavant déchiffrer le chiffré auparavant.
...
Je _pense_ le contraire naturellement. Afin de trancher, fournit une
implémentation de l'ensemble. Afin que nous puissions y *réfléchir*.
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Ici, je me limitais à parler de l'attaque mentionnée dans mes
derniers
messages: celui où on peut savoir quelques caractères d'un en-tête ayant
toujours ou presque les même caractères pour identifier le fichier.
Exemple, l'extension jpeg contient un en-tête propre à lui et si l'on
connaît l'extension on connaît donc cet en-tête et on peut deviner
certains
caractères du chiffré. Mais, sûrement vous saviez que c'est de cela dont
je
parlais.
Non. Je ne devine pas. Je suis absolument dépourvu de cette capacité. En
cas de doute, je préfère poser la question. Ta réponse faisait
naturellement partie des possibles.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris.
...
Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
...
Faudrait relire plus attentivement mon explication qui est quand même
assez clair à cause de l'exemple donné.
Il serait utile d'adopter un autre ton envers quelqu'un qui t'aide
bénévolement et qui met publiquement ses preuves à disposition.
J'ai des chiffrés et leurs clairs.
Je pense que vous n'avez aucune chance de débrouiller le clair
puisqu'il
faudrait auparavant déchiffrer le chiffré auparavant.
...
Je _pense_ le contraire naturellement. Afin de trancher, fournit une
implémentation de l'ensemble. Afin que nous puissions y *réfléchir*.
Mauvaise réponse :-o Une attaque à clair connu est censée se faire avec
un chiffré et un clair *complet*, pas seulement le nom du fichier.
Ici, je me limitais à parler de l'attaque mentionnée dans mes
derniers
messages: celui où on peut savoir quelques caractères d'un en-tête ayant
toujours ou presque les même caractères pour identifier le fichier.
Exemple, l'extension jpeg contient un en-tête propre à lui et si l'on
connaît l'extension on connaît donc cet en-tête et on peut deviner
certains
caractères du chiffré. Mais, sûrement vous saviez que c'est de cela dont
je
parlais.
Non. Je ne devine pas. Je suis absolument dépourvu de cette capacité. En
cas de doute, je préfère poser la question. Ta réponse faisait
naturellement partie des possibles.
Autrement dit tu procède à un brouillage du clair dont le procédé ne
dépend pas d'une clé.
Il semble que vous n'ayez pas vraiment compris.
...Si tu numérote de 0 à 9 : il y a dix caractères et le dernier
caractères est le _dixième_ et qui a le _rang_ 9.
...
Faudrait relire plus attentivement mon explication qui est quand même
assez clair à cause de l'exemple donné.
Il serait utile d'adopter un autre ton envers quelqu'un qui t'aide
bénévolement et qui met publiquement ses preuves à disposition.
J'ai des chiffrés et leurs clairs.
Je pense que vous n'avez aucune chance de débrouiller le clair
puisqu'il
faudrait auparavant déchiffrer le chiffré auparavant.
...
Je _pense_ le contraire naturellement. Afin de trancher, fournit une
implémentation de l'ensemble. Afin que nous puissions y *réfléchir*.
...je voulais juste vous encourager à relire attentivement ce que
j'avais écrit dans mon message précédent car avec l'exemple on voit
ce que je voulais dire. C'est pourquoi je jugeait qu'il n'était pas
nécessaire que je ré explique la même chose ici en me répétant.
Car il arrive qu'en lisant la même chose une 2e fois qu'on voit les
choses sous un autre angle.
...
de session par la phrase de passe car je ne suis pas rendue à cette
étape encore. Voulez-vous quand même que je vous envoie un exemple
mais sans la clef de session finale (clef qui devrait être chiffré par
la phrase de passe) ?
...
clair brouillé et chiffré. Bien entendu s'il s'avérait que je me
trompe alors tant mieux si on le prouve car je préfère cela ainsi
qu'on le démontre.
...je voulais juste vous encourager à relire attentivement ce que
j'avais écrit dans mon message précédent car avec l'exemple on voit
ce que je voulais dire. C'est pourquoi je jugeait qu'il n'était pas
nécessaire que je ré explique la même chose ici en me répétant.
Car il arrive qu'en lisant la même chose une 2e fois qu'on voit les
choses sous un autre angle.
...
de session par la phrase de passe car je ne suis pas rendue à cette
étape encore. Voulez-vous quand même que je vous envoie un exemple
mais sans la clef de session finale (clef qui devrait être chiffré par
la phrase de passe) ?
...
clair brouillé et chiffré. Bien entendu s'il s'avérait que je me
trompe alors tant mieux si on le prouve car je préfère cela ainsi
qu'on le démontre.
...je voulais juste vous encourager à relire attentivement ce que
j'avais écrit dans mon message précédent car avec l'exemple on voit
ce que je voulais dire. C'est pourquoi je jugeait qu'il n'était pas
nécessaire que je ré explique la même chose ici en me répétant.
Car il arrive qu'en lisant la même chose une 2e fois qu'on voit les
choses sous un autre angle.
...
de session par la phrase de passe car je ne suis pas rendue à cette
étape encore. Voulez-vous quand même que je vous envoie un exemple
mais sans la clef de session finale (clef qui devrait être chiffré par
la phrase de passe) ?
...
clair brouillé et chiffré. Bien entendu s'il s'avérait que je me
trompe alors tant mieux si on le prouve car je préfère cela ainsi
qu'on le démontre.
Autrement dit, dans l'algo de Vernam il n'y aurait aucune
différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution
poly-alphabétique. Addition ou xor, même combat.
Autrement dit, dans l'algo de Vernam il n'y aurait aucune
différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution
poly-alphabétique. Addition ou xor, même combat.
Autrement dit, dans l'algo de Vernam il n'y aurait aucune
différence qu'il ait utilisé soit un xor ou une addition?
Tout à fait. Il s'agit d'une substitution
poly-alphabétique. Addition ou xor, même combat.
ÉTAPE 1: incrémentation de chaque caractère ascii de Clair1.
On incrémente de 'un' chaque caractères du Clair1 pour donner Clair2.
Ceci est pour diversifier d'avantage les caractères de la clef de session
complète si Clair1 comportait plusieurs caractères ascii zéro de suite.
ÉTAPE 2: création de la clef de session complète.
Avec la formule suivante, et influencé par Clair2, on crée la clef
complète à partir de la clef de session initiale:
(k1+k2) xor (m1+k3) = dernier octet ajouté à k
ÉTAPE 3: permutation des octets de Clair2.
m = 050-024-047-115-128-089-051-063-064 = Clair2
Donc, clair2 devient clair3 en permutant Clair2 de la façon qui suit.
On fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute avec les caractères 1 à 8, puis 5 à 12, 9 à 16, 13 à
20, etc. C'est le 9e caractère qui indique lequel des 10 choix de
permutation utiliser pour permuter les 8 caractères qui le précèdent.
ÉTAPE 4: chiffrage de Clair3 via un xor à partir de la clef de session
complète.
Donc, dans notre exemple, se serait seulement le chiffré qui serait
connu,
Il est vrai qu'il serait plus facile dans notre petit exemple de faire
une attaque à force brute ou faire des essaie de valeurs jusqu'à ce
que le tout corresponde, mais il faut aussi tenir compte que la clef de
session initiale (donc finale aussi) aura un minimum d'octet (peut-être
128 bits)
Si vous réussissez à faire une attaque à clair connue je vous
envoie un chiffré et son clair1 (en partie) pour refaire la
démonstration (car le clair ne peut pas vraiment être connu au complet
puisque sinon on aurait pas à faire d'attaque du tout puisqu'on aurait
déjà le clair1.
C'est un système à clef jetable automatiquement.
ÉTAPE 1: incrémentation de chaque caractère ascii de Clair1.
On incrémente de 'un' chaque caractères du Clair1 pour donner Clair2.
Ceci est pour diversifier d'avantage les caractères de la clef de session
complète si Clair1 comportait plusieurs caractères ascii zéro de suite.
ÉTAPE 2: création de la clef de session complète.
Avec la formule suivante, et influencé par Clair2, on crée la clef
complète à partir de la clef de session initiale:
(k1+k2) xor (m1+k3) = dernier octet ajouté à k
ÉTAPE 3: permutation des octets de Clair2.
m = 050-024-047-115-128-089-051-063-064 = Clair2
Donc, clair2 devient clair3 en permutant Clair2 de la façon qui suit.
On fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute avec les caractères 1 à 8, puis 5 à 12, 9 à 16, 13 à
20, etc. C'est le 9e caractère qui indique lequel des 10 choix de
permutation utiliser pour permuter les 8 caractères qui le précèdent.
ÉTAPE 4: chiffrage de Clair3 via un xor à partir de la clef de session
complète.
Donc, dans notre exemple, se serait seulement le chiffré qui serait
connu,
Il est vrai qu'il serait plus facile dans notre petit exemple de faire
une attaque à force brute ou faire des essaie de valeurs jusqu'à ce
que le tout corresponde, mais il faut aussi tenir compte que la clef de
session initiale (donc finale aussi) aura un minimum d'octet (peut-être
128 bits)
Si vous réussissez à faire une attaque à clair connue je vous
envoie un chiffré et son clair1 (en partie) pour refaire la
démonstration (car le clair ne peut pas vraiment être connu au complet
puisque sinon on aurait pas à faire d'attaque du tout puisqu'on aurait
déjà le clair1.
C'est un système à clef jetable automatiquement.
ÉTAPE 1: incrémentation de chaque caractère ascii de Clair1.
On incrémente de 'un' chaque caractères du Clair1 pour donner Clair2.
Ceci est pour diversifier d'avantage les caractères de la clef de session
complète si Clair1 comportait plusieurs caractères ascii zéro de suite.
ÉTAPE 2: création de la clef de session complète.
Avec la formule suivante, et influencé par Clair2, on crée la clef
complète à partir de la clef de session initiale:
(k1+k2) xor (m1+k3) = dernier octet ajouté à k
ÉTAPE 3: permutation des octets de Clair2.
m = 050-024-047-115-128-089-051-063-064 = Clair2
Donc, clair2 devient clair3 en permutant Clair2 de la façon qui suit.
On fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute avec les caractères 1 à 8, puis 5 à 12, 9 à 16, 13 à
20, etc. C'est le 9e caractère qui indique lequel des 10 choix de
permutation utiliser pour permuter les 8 caractères qui le précèdent.
ÉTAPE 4: chiffrage de Clair3 via un xor à partir de la clef de session
complète.
Donc, dans notre exemple, se serait seulement le chiffré qui serait
connu,
Il est vrai qu'il serait plus facile dans notre petit exemple de faire
une attaque à force brute ou faire des essaie de valeurs jusqu'à ce
que le tout corresponde, mais il faut aussi tenir compte que la clef de
session initiale (donc finale aussi) aura un minimum d'octet (peut-être
128 bits)
Si vous réussissez à faire une attaque à clair connue je vous
envoie un chiffré et son clair1 (en partie) pour refaire la
démonstration (car le clair ne peut pas vraiment être connu au complet
puisque sinon on aurait pas à faire d'attaque du tout puisqu'on aurait
déjà le clair1.
C'est un système à clef jetable automatiquement.
Bonjour :-)
Ton descriptif étant relativement long, je vais prendre chaque étape et
la traduire en termes plus courts.
ÉTAPE 1: incrémentation de chaque caractère ascii de Clair1.
On incrémente de 'un' chaque caractères du Clair1 pour donner Clair2.
Ceci est pour diversifier d'avantage les caractères de la clef de session
complète si Clair1 comportait plusieurs caractères ascii zéro de suite.
Il s'agit donc d'un brouillage du clair. Un traitement sur le clair
par substitutions sans utiliser de réglages externes, on le transforme.
Soit inc() la fonction utilisée : Clair2 = inc(Clair1)
ÉTAPE 2: création de la clef de session complète.
Avec la formule suivante, et influencé par Clair2, on crée la clef
complète à partir de la clef de session initiale:
(k1+k2) xor (m1+k3) = dernier octet ajouté à k
A partir de Clair2 et de la clef de "session initiale" (que je note ki) on
calcule k, la clé de session complète.
k = ses(Clair2,ki)
"ses" étant la représentation mathématique du traitement concernant
Clair2 et ki pour obtenir la clé de session complète, k.
Note que s'il faut Clair2 pour transformer ki en k, trouver ki à partir
de k est facile : ce sont les premiers octets de k.
Soit ses_1() la fonction (plus ou moins...) réciproque de ses telle que :
ki = ses_1(k). Elle sera utilisée plus loin.
ÉTAPE 3: permutation des octets de Clair2.
m = 050-024-047-115-128-089-051-063-064 = Clair2
Donc, clair2 devient clair3 en permutant Clair2 de la façon qui suit.
On fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute avec les caractères 1 à 8, puis 5 à 12, 9 à 16, 13
à
20, etc. C'est le 9e caractère qui indique lequel des 10 choix de
permutation utiliser pour permuter les 8 caractères qui le précèdent.
Clair2 subit une permutation sans intervention extérieure, une
transposition, notée per(). Les grilles de permutations font parties de
l'algorithme.
Clair3 = per(Clair2)
ÉTAPE 4: chiffrage de Clair3 via un xor à partir de la clef de session
complète.
Le chiffré "c", est obtenu au moyen du xorage de Clair3 et de k.
c = xor(Clair3,k)
Cryptanalyse :
c = xor(Clair3,k)
c = xor(per(Clair2),ses(Clair2,ki)) (remplaçant Clair3 et k)
c = xor( per(inc(Clair1)) , ses(inc(Clair1),ki) )
L'hypothèse est que je dispose de "Clair1", de "c" et de l'algorithme. Je
vais marquer les parties connues par des lettres capitales (X, Y...) pour
clarifier l'exposé.
c est connu
Clair1 est connu
donc inc(Clair1) est connu
et per(inc(Clair1)) est connu
L'équation devient : C = xor( X, ses(Y,ki) )
En utilisant la propriété du xor (noté "plus") : a = b+c <=> a+c = b
L'équation devient :
ses(Y,ki) = xor(C,X)
C et X étant connus, xor(C,X) l'est aussi :
ses(Y,ki) = Z.
ki = ses_1(Z)
Autre manière d'écrire la même chose :
c = xor( per(inc(Clair1)) , ses(inc(Clair1),ki) )
ses(inc(Clair1),ki) = xor (c,per(inc(Clair1)))
ki = ses_1(xor(c,per(inc(Clair1))))
ki est donc calculable intégralement à partir du chiffré et du clair.
Donc, dans notre exemple, se serait seulement le chiffré qui serait
connu,
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors, je
suis bêtement la doctrine...
Si vous réussissez à faire une attaque à clair connue je vous
envoie un chiffré et son clair1 (en partie) pour refaire la
démonstration (car le clair ne peut pas vraiment être connu au complet
puisque sinon on aurait pas à faire d'attaque du tout puisqu'on aurait
déjà le clair1.
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Bonjour :-)
Ton descriptif étant relativement long, je vais prendre chaque étape et
la traduire en termes plus courts.
ÉTAPE 1: incrémentation de chaque caractère ascii de Clair1.
On incrémente de 'un' chaque caractères du Clair1 pour donner Clair2.
Ceci est pour diversifier d'avantage les caractères de la clef de session
complète si Clair1 comportait plusieurs caractères ascii zéro de suite.
Il s'agit donc d'un brouillage du clair. Un traitement sur le clair
par substitutions sans utiliser de réglages externes, on le transforme.
Soit inc() la fonction utilisée : Clair2 = inc(Clair1)
ÉTAPE 2: création de la clef de session complète.
Avec la formule suivante, et influencé par Clair2, on crée la clef
complète à partir de la clef de session initiale:
(k1+k2) xor (m1+k3) = dernier octet ajouté à k
A partir de Clair2 et de la clef de "session initiale" (que je note ki) on
calcule k, la clé de session complète.
k = ses(Clair2,ki)
"ses" étant la représentation mathématique du traitement concernant
Clair2 et ki pour obtenir la clé de session complète, k.
Note que s'il faut Clair2 pour transformer ki en k, trouver ki à partir
de k est facile : ce sont les premiers octets de k.
Soit ses_1() la fonction (plus ou moins...) réciproque de ses telle que :
ki = ses_1(k). Elle sera utilisée plus loin.
ÉTAPE 3: permutation des octets de Clair2.
m = 050-024-047-115-128-089-051-063-064 = Clair2
Donc, clair2 devient clair3 en permutant Clair2 de la façon qui suit.
On fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute avec les caractères 1 à 8, puis 5 à 12, 9 à 16, 13
à
20, etc. C'est le 9e caractère qui indique lequel des 10 choix de
permutation utiliser pour permuter les 8 caractères qui le précèdent.
Clair2 subit une permutation sans intervention extérieure, une
transposition, notée per(). Les grilles de permutations font parties de
l'algorithme.
Clair3 = per(Clair2)
ÉTAPE 4: chiffrage de Clair3 via un xor à partir de la clef de session
complète.
Le chiffré "c", est obtenu au moyen du xorage de Clair3 et de k.
c = xor(Clair3,k)
Cryptanalyse :
c = xor(Clair3,k)
c = xor(per(Clair2),ses(Clair2,ki)) (remplaçant Clair3 et k)
c = xor( per(inc(Clair1)) , ses(inc(Clair1),ki) )
L'hypothèse est que je dispose de "Clair1", de "c" et de l'algorithme. Je
vais marquer les parties connues par des lettres capitales (X, Y...) pour
clarifier l'exposé.
c est connu
Clair1 est connu
donc inc(Clair1) est connu
et per(inc(Clair1)) est connu
L'équation devient : C = xor( X, ses(Y,ki) )
En utilisant la propriété du xor (noté "plus") : a = b+c <=> a+c = b
L'équation devient :
ses(Y,ki) = xor(C,X)
C et X étant connus, xor(C,X) l'est aussi :
ses(Y,ki) = Z.
ki = ses_1(Z)
Autre manière d'écrire la même chose :
c = xor( per(inc(Clair1)) , ses(inc(Clair1),ki) )
ses(inc(Clair1),ki) = xor (c,per(inc(Clair1)))
ki = ses_1(xor(c,per(inc(Clair1))))
ki est donc calculable intégralement à partir du chiffré et du clair.
Donc, dans notre exemple, se serait seulement le chiffré qui serait
connu,
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors, je
suis bêtement la doctrine...
Si vous réussissez à faire une attaque à clair connue je vous
envoie un chiffré et son clair1 (en partie) pour refaire la
démonstration (car le clair ne peut pas vraiment être connu au complet
puisque sinon on aurait pas à faire d'attaque du tout puisqu'on aurait
déjà le clair1.
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Bonjour :-)
Ton descriptif étant relativement long, je vais prendre chaque étape et
la traduire en termes plus courts.
ÉTAPE 1: incrémentation de chaque caractère ascii de Clair1.
On incrémente de 'un' chaque caractères du Clair1 pour donner Clair2.
Ceci est pour diversifier d'avantage les caractères de la clef de session
complète si Clair1 comportait plusieurs caractères ascii zéro de suite.
Il s'agit donc d'un brouillage du clair. Un traitement sur le clair
par substitutions sans utiliser de réglages externes, on le transforme.
Soit inc() la fonction utilisée : Clair2 = inc(Clair1)
ÉTAPE 2: création de la clef de session complète.
Avec la formule suivante, et influencé par Clair2, on crée la clef
complète à partir de la clef de session initiale:
(k1+k2) xor (m1+k3) = dernier octet ajouté à k
A partir de Clair2 et de la clef de "session initiale" (que je note ki) on
calcule k, la clé de session complète.
k = ses(Clair2,ki)
"ses" étant la représentation mathématique du traitement concernant
Clair2 et ki pour obtenir la clé de session complète, k.
Note que s'il faut Clair2 pour transformer ki en k, trouver ki à partir
de k est facile : ce sont les premiers octets de k.
Soit ses_1() la fonction (plus ou moins...) réciproque de ses telle que :
ki = ses_1(k). Elle sera utilisée plus loin.
ÉTAPE 3: permutation des octets de Clair2.
m = 050-024-047-115-128-089-051-063-064 = Clair2
Donc, clair2 devient clair3 en permutant Clair2 de la façon qui suit.
On fait la permutation par groupe de 8 caractères à tous les 4
caractères. On débute avec les caractères 1 à 8, puis 5 à 12, 9 à 16, 13
à
20, etc. C'est le 9e caractère qui indique lequel des 10 choix de
permutation utiliser pour permuter les 8 caractères qui le précèdent.
Clair2 subit une permutation sans intervention extérieure, une
transposition, notée per(). Les grilles de permutations font parties de
l'algorithme.
Clair3 = per(Clair2)
ÉTAPE 4: chiffrage de Clair3 via un xor à partir de la clef de session
complète.
Le chiffré "c", est obtenu au moyen du xorage de Clair3 et de k.
c = xor(Clair3,k)
Cryptanalyse :
c = xor(Clair3,k)
c = xor(per(Clair2),ses(Clair2,ki)) (remplaçant Clair3 et k)
c = xor( per(inc(Clair1)) , ses(inc(Clair1),ki) )
L'hypothèse est que je dispose de "Clair1", de "c" et de l'algorithme. Je
vais marquer les parties connues par des lettres capitales (X, Y...) pour
clarifier l'exposé.
c est connu
Clair1 est connu
donc inc(Clair1) est connu
et per(inc(Clair1)) est connu
L'équation devient : C = xor( X, ses(Y,ki) )
En utilisant la propriété du xor (noté "plus") : a = b+c <=> a+c = b
L'équation devient :
ses(Y,ki) = xor(C,X)
C et X étant connus, xor(C,X) l'est aussi :
ses(Y,ki) = Z.
ki = ses_1(Z)
Autre manière d'écrire la même chose :
c = xor( per(inc(Clair1)) , ses(inc(Clair1),ki) )
ses(inc(Clair1),ki) = xor (c,per(inc(Clair1)))
ki = ses_1(xor(c,per(inc(Clair1))))
ki est donc calculable intégralement à partir du chiffré et du clair.
Donc, dans notre exemple, se serait seulement le chiffré qui serait
connu,
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors, je
suis bêtement la doctrine...
Si vous réussissez à faire une attaque à clair connue je vous
envoie un chiffré et son clair1 (en partie) pour refaire la
démonstration (car le clair ne peut pas vraiment être connu au complet
puisque sinon on aurait pas à faire d'attaque du tout puisqu'on aurait
déjà le clair1.
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
-> Par ailleurs, j'ai suffisamment prouvé que la "science" pouvait venir
-> à
-> bout des versions du simple algo. Lis mes calculs, et on discute le
-> concept.
En plus, vous appelez cela une preuve.
Mais je vois que votre conclusion est erronée concernant (votre
théorie) le fait que vos calculs servent à la cryptanalyse du 'Simple
algo'. Aucune preuve n'est donnée pour prouver que le 'Simple algo' de
cette étape-ci est faible.
Donc via '+Var1(x+1)':
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Cryptanalyse :
Ce qui suit n'est pas de la cryptanalyse.
"La cryptanalyse est tout simplement l'art de rendre clair un texte
crypté sans avoir connaissance de la clef utilisée.
http://mantis.free.fr/articles/analyse.htm " Or, vos effort sont pour
prouver qu'il est possible de connaître la clef à partir du CLAIR
DÉJÀ CONNU.
...
Je veux dire que casser le 'Simple algo' signifie trouver le clair;
mais ici on aurait déjà le clair, donc le reste ne sert plus à rien
et le 'Simple algo' à cette étape-ci reste fort. Hé oui! Jusqu'à
preuve du contraire :-)
Alors, pourquoi tenter de trouver la clef initiale à partir de ce
clair? Cette clef n'est plus utilisable et est jetable. Il serait
préférable de la laisser à la poubelle ;-) Je vous taquine :-)
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
Le 'Simple algo' est inspiré de celui de Varnam et est un crypto
système à clef jetable, donc inutile de ramasser les clefs à la
poubelle ;-)
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Si vous voulez dire qu'il vous faut tout le clair avant de tenter
une attaque à clair connu, alors ce principe ne s'applique pas au
'Simple algo' de cette étape-ci, et pas plus à l'algo de Vernam.
Puisque ce sont deux systèmes à 'clef jetable' (One time pad). Du
même coup ce principe ne s'appliquera pas à AllCrypter si celui-ci,
dans sa version 3, tire son inspiration de cette étape-ci.
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
-> Par ailleurs, j'ai suffisamment prouvé que la "science" pouvait venir
-> à
-> bout des versions du simple algo. Lis mes calculs, et on discute le
-> concept.
En plus, vous appelez cela une preuve.
Mais je vois que votre conclusion est erronée concernant (votre
théorie) le fait que vos calculs servent à la cryptanalyse du 'Simple
algo'. Aucune preuve n'est donnée pour prouver que le 'Simple algo' de
cette étape-ci est faible.
Donc via '+Var1(x+1)':
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Cryptanalyse :
Ce qui suit n'est pas de la cryptanalyse.
"La cryptanalyse est tout simplement l'art de rendre clair un texte
crypté sans avoir connaissance de la clef utilisée.
http://mantis.free.fr/articles/analyse.htm " Or, vos effort sont pour
prouver qu'il est possible de connaître la clef à partir du CLAIR
DÉJÀ CONNU.
...
Je veux dire que casser le 'Simple algo' signifie trouver le clair;
mais ici on aurait déjà le clair, donc le reste ne sert plus à rien
et le 'Simple algo' à cette étape-ci reste fort. Hé oui! Jusqu'à
preuve du contraire :-)
Alors, pourquoi tenter de trouver la clef initiale à partir de ce
clair? Cette clef n'est plus utilisable et est jetable. Il serait
préférable de la laisser à la poubelle ;-) Je vous taquine :-)
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
Le 'Simple algo' est inspiré de celui de Varnam et est un crypto
système à clef jetable, donc inutile de ramasser les clefs à la
poubelle ;-)
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Si vous voulez dire qu'il vous faut tout le clair avant de tenter
une attaque à clair connu, alors ce principe ne s'applique pas au
'Simple algo' de cette étape-ci, et pas plus à l'algo de Vernam.
Puisque ce sont deux systèmes à 'clef jetable' (One time pad). Du
même coup ce principe ne s'appliquera pas à AllCrypter si celui-ci,
dans sa version 3, tire son inspiration de cette étape-ci.
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
-> Par ailleurs, j'ai suffisamment prouvé que la "science" pouvait venir
-> à
-> bout des versions du simple algo. Lis mes calculs, et on discute le
-> concept.
En plus, vous appelez cela une preuve.
Mais je vois que votre conclusion est erronée concernant (votre
théorie) le fait que vos calculs servent à la cryptanalyse du 'Simple
algo'. Aucune preuve n'est donnée pour prouver que le 'Simple algo' de
cette étape-ci est faible.
Donc via '+Var1(x+1)':
...
Donc, pour défaire la permutation il faut avoir trouvé la dernière
valeur utilisée à la fin du fichier, et cette valeur (avec le code
d'identification et la clef de session finale) est chiffrée (chiffré2)
par la phrase de passe puis associé au chiffré 1.
Cryptanalyse :
Ce qui suit n'est pas de la cryptanalyse.
"La cryptanalyse est tout simplement l'art de rendre clair un texte
crypté sans avoir connaissance de la clef utilisée.
http://mantis.free.fr/articles/analyse.htm " Or, vos effort sont pour
prouver qu'il est possible de connaître la clef à partir du CLAIR
DÉJÀ CONNU.
...
Je veux dire que casser le 'Simple algo' signifie trouver le clair;
mais ici on aurait déjà le clair, donc le reste ne sert plus à rien
et le 'Simple algo' à cette étape-ci reste fort. Hé oui! Jusqu'à
preuve du contraire :-)
Alors, pourquoi tenter de trouver la clef initiale à partir de ce
clair? Cette clef n'est plus utilisable et est jetable. Il serait
préférable de la laisser à la poubelle ;-) Je vous taquine :-)
Je reste sur les attaques à clair connu. La doctrine affirme qu'un
cryptosystème ne passant pas cette phase ne vaut pas le coup. Alors,
je suis bêtement la doctrine...
Mais, cette doctrine n'est pas applicable à l'algo de Vernam, le seul
algo indéchiffrable, donc le seul algo qui vaudrait le coup à 100% :-)
Le 'Simple algo' est inspiré de celui de Varnam et est un crypto
système à clef jetable, donc inutile de ramasser les clefs à la
poubelle ;-)
Pas d'accord. Vu l'empilement de calculs, ça commence à faire un peu
long pour moi. Le principe d'une attaque à clair connu est que,
justement, on a tout le clair. Pas une partie.
Si vous voulez dire qu'il vous faut tout le clair avant de tenter
une attaque à clair connu, alors ce principe ne s'applique pas au
'Simple algo' de cette étape-ci, et pas plus à l'algo de Vernam.
Puisque ce sont deux systèmes à 'clef jetable' (One time pad). Du
même coup ce principe ne s'appliquera pas à AllCrypter si celui-ci,
dans sa version 3, tire son inspiration de cette étape-ci.
Mais, j'avais pensé que vous demanderiez un chiffré et une partie
de son clair (les premier caractères du clair) qui correspond à la
même longueur que la clef de session initiale. Cela aurait été
équitable pour tenter de trouver le clair au complet afin de prouver si
oui ou non c'est possible.
