Et tout en essayant, dans la mesure du possible, d'utiliser des
calculs
simples pour que plus de gens puissent suivre et participer. Je dirais
peut-être à la limite utiliser l'algèbre du niveau secondaire.
Bien entendu la chaîne généré ne doit pas
être plus courte que la clef elle-même puisqu'il y aurait plus d'une
clef qui donnerait le même résultat. Je pense qu'il pourrait être
possible que la même chaîne ou la même sous-clef générée ne puisse
être générée par une clef différente et que de ce fait aucune
collision ne soit possible dans ce sens. Faudrait que je teste cela en
programmation dans l'exemple d'une boucle qui génère toutes les clefs
possibles en 32 bits par exemple.
C1 + C2 = M1 + K + M2 + K
Donc : C1 + C2 = M1 + M2
Je pense que ce dernier exemple (C1 + C2 = M1 + M2) fausserait le
résultat, dans le sens que je ne crois pas que l'algèbre permette
l'annulation de K ici:
1- puisque la valeur de K n'est pas connue.
2- puisque sur un même côté
du signe '=' 'il faudrait que l'une des deux variables K soit négative et
l'autre positive
3- puisqu'il faudrait qu'il y ait de chaque côté du
signe '=' un pôle identique de K, soit positif ou soit négatif.
Par contre on peut trouver la valeur de K en connaissant les valeurs de
M1, M2, C1 et C2 (donc avec une même clef chiffrant deux clairs
différents).
C1 = M1 + K (exemple: 7 = 4 + 3 )
C2 = M2 + K (exemple: 11 = 8 + 3 )
C'est un peu long à approcher, mais la clé peut être annulée par ce
type de procédé. Donc, on connaît une donnée supplémentaire "M1 +
M2", en très gros,
M1 chiffré avec M2.
Ici, je ne suis pas certain du raisonnement "M1 chiffré avec M2". Ne
voulez-vous pas dire "M1 et M2 chiffrés ensemble"?
D'une manière générale,
Auriez-vous un petit exemple d'exception qui pourrait s'ajouter au 'simple
algo'?
comme xor, la réutilisation de la clé ou sa longueur inférieure à
celle du message constitue une faiblesse *grave*. Dans ces conditions,
la cryptanalyse n'est qu'une affaire de temps très court s'il y a
beaucoup de chiffrés d'interceptés, tous conçus avec la même clé.
Tout en connaissent l'algo, à moins d'avoir des répétitions comme les
entêtes.
...
5 - 5 = 0
5 - 6 = 9 ( 5-6=-1, (-1)+10=9 )
5 - 7 = 8
5 - 8 = 7
5 - 9 = 6
La quelle est la bonne ? Chacun des clairs proposés est équiprobable.
En fait, soient C et M un chiffré qu'on connait et M un mot choisi. Il
sera toujour possible de trouver un clé K telle que : C = M + K.
Je ne vois pas très bien comment il est possible dans cet exemple de
trouver le clair sans la clef.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur à
calculer dans la clef afin d'interdire de trouver la clef par une attaque
à clair connue.
Dans cette option on suppose longueur de la clef est
toujours à la longueur du clair afin d'éviter les répétitions.
J'essaie de faire le plus simple possible
On a:
49 50 51 = clef
51 52 53 = texte clair
202 206 204 = chiffré
On crypte ainsi:
k1 + k2 + m1 + m2 = c1 = 202
k2 + k3 + m2 + m3 = c2 = 206
k3 + k1(qui prend la place de 'k4' qui n'existe pas) + m3 + k1(qui prend
la place du caractère 'm4' qui n'existe pas) = c3 = 204
Ici, vous est-il possible de faire une attaque à clair pour trouver la
clef manquante?
? ? ? = clef
51 52 53 = texte clair
249 281 216 = chiffré
Et tout en essayant, dans la mesure du possible, d'utiliser des
calculs
simples pour que plus de gens puissent suivre et participer. Je dirais
peut-être à la limite utiliser l'algèbre du niveau secondaire.
Bien entendu la chaîne généré ne doit pas
être plus courte que la clef elle-même puisqu'il y aurait plus d'une
clef qui donnerait le même résultat. Je pense qu'il pourrait être
possible que la même chaîne ou la même sous-clef générée ne puisse
être générée par une clef différente et que de ce fait aucune
collision ne soit possible dans ce sens. Faudrait que je teste cela en
programmation dans l'exemple d'une boucle qui génère toutes les clefs
possibles en 32 bits par exemple.
C1 + C2 = M1 + K + M2 + K
Donc : C1 + C2 = M1 + M2
Je pense que ce dernier exemple (C1 + C2 = M1 + M2) fausserait le
résultat, dans le sens que je ne crois pas que l'algèbre permette
l'annulation de K ici:
1- puisque la valeur de K n'est pas connue.
2- puisque sur un même côté
du signe '=' 'il faudrait que l'une des deux variables K soit négative et
l'autre positive
3- puisqu'il faudrait qu'il y ait de chaque côté du
signe '=' un pôle identique de K, soit positif ou soit négatif.
Par contre on peut trouver la valeur de K en connaissant les valeurs de
M1, M2, C1 et C2 (donc avec une même clef chiffrant deux clairs
différents).
C1 = M1 + K (exemple: 7 = 4 + 3 )
C2 = M2 + K (exemple: 11 = 8 + 3 )
C'est un peu long à approcher, mais la clé peut être annulée par ce
type de procédé. Donc, on connaît une donnée supplémentaire "M1 +
M2", en très gros,
M1 chiffré avec M2.
Ici, je ne suis pas certain du raisonnement "M1 chiffré avec M2". Ne
voulez-vous pas dire "M1 et M2 chiffrés ensemble"?
D'une manière générale,
Auriez-vous un petit exemple d'exception qui pourrait s'ajouter au 'simple
algo'?
comme xor, la réutilisation de la clé ou sa longueur inférieure à
celle du message constitue une faiblesse *grave*. Dans ces conditions,
la cryptanalyse n'est qu'une affaire de temps très court s'il y a
beaucoup de chiffrés d'interceptés, tous conçus avec la même clé.
Tout en connaissent l'algo, à moins d'avoir des répétitions comme les
entêtes.
...
5 - 5 = 0
5 - 6 = 9 ( 5-6=-1, (-1)+10=9 )
5 - 7 = 8
5 - 8 = 7
5 - 9 = 6
La quelle est la bonne ? Chacun des clairs proposés est équiprobable.
En fait, soient C et M un chiffré qu'on connait et M un mot choisi. Il
sera toujour possible de trouver un clé K telle que : C = M + K.
Je ne vois pas très bien comment il est possible dans cet exemple de
trouver le clair sans la clef.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur à
calculer dans la clef afin d'interdire de trouver la clef par une attaque
à clair connue.
Dans cette option on suppose longueur de la clef est
toujours à la longueur du clair afin d'éviter les répétitions.
J'essaie de faire le plus simple possible
On a:
49 50 51 = clef
51 52 53 = texte clair
202 206 204 = chiffré
On crypte ainsi:
k1 + k2 + m1 + m2 = c1 = 202
k2 + k3 + m2 + m3 = c2 = 206
k3 + k1(qui prend la place de 'k4' qui n'existe pas) + m3 + k1(qui prend
la place du caractère 'm4' qui n'existe pas) = c3 = 204
Ici, vous est-il possible de faire une attaque à clair pour trouver la
clef manquante?
? ? ? = clef
51 52 53 = texte clair
249 281 216 = chiffré
Et tout en essayant, dans la mesure du possible, d'utiliser des
calculs
simples pour que plus de gens puissent suivre et participer. Je dirais
peut-être à la limite utiliser l'algèbre du niveau secondaire.
Bien entendu la chaîne généré ne doit pas
être plus courte que la clef elle-même puisqu'il y aurait plus d'une
clef qui donnerait le même résultat. Je pense qu'il pourrait être
possible que la même chaîne ou la même sous-clef générée ne puisse
être générée par une clef différente et que de ce fait aucune
collision ne soit possible dans ce sens. Faudrait que je teste cela en
programmation dans l'exemple d'une boucle qui génère toutes les clefs
possibles en 32 bits par exemple.
C1 + C2 = M1 + K + M2 + K
Donc : C1 + C2 = M1 + M2
Je pense que ce dernier exemple (C1 + C2 = M1 + M2) fausserait le
résultat, dans le sens que je ne crois pas que l'algèbre permette
l'annulation de K ici:
1- puisque la valeur de K n'est pas connue.
2- puisque sur un même côté
du signe '=' 'il faudrait que l'une des deux variables K soit négative et
l'autre positive
3- puisqu'il faudrait qu'il y ait de chaque côté du
signe '=' un pôle identique de K, soit positif ou soit négatif.
Par contre on peut trouver la valeur de K en connaissant les valeurs de
M1, M2, C1 et C2 (donc avec une même clef chiffrant deux clairs
différents).
C1 = M1 + K (exemple: 7 = 4 + 3 )
C2 = M2 + K (exemple: 11 = 8 + 3 )
C'est un peu long à approcher, mais la clé peut être annulée par ce
type de procédé. Donc, on connaît une donnée supplémentaire "M1 +
M2", en très gros,
M1 chiffré avec M2.
Ici, je ne suis pas certain du raisonnement "M1 chiffré avec M2". Ne
voulez-vous pas dire "M1 et M2 chiffrés ensemble"?
D'une manière générale,
Auriez-vous un petit exemple d'exception qui pourrait s'ajouter au 'simple
algo'?
comme xor, la réutilisation de la clé ou sa longueur inférieure à
celle du message constitue une faiblesse *grave*. Dans ces conditions,
la cryptanalyse n'est qu'une affaire de temps très court s'il y a
beaucoup de chiffrés d'interceptés, tous conçus avec la même clé.
Tout en connaissent l'algo, à moins d'avoir des répétitions comme les
entêtes.
...
5 - 5 = 0
5 - 6 = 9 ( 5-6=-1, (-1)+10=9 )
5 - 7 = 8
5 - 8 = 7
5 - 9 = 6
La quelle est la bonne ? Chacun des clairs proposés est équiprobable.
En fait, soient C et M un chiffré qu'on connait et M un mot choisi. Il
sera toujour possible de trouver un clé K telle que : C = M + K.
Je ne vois pas très bien comment il est possible dans cet exemple de
trouver le clair sans la clef.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur à
calculer dans la clef afin d'interdire de trouver la clef par une attaque
à clair connue.
Dans cette option on suppose longueur de la clef est
toujours à la longueur du clair afin d'éviter les répétitions.
J'essaie de faire le plus simple possible
On a:
49 50 51 = clef
51 52 53 = texte clair
202 206 204 = chiffré
On crypte ainsi:
k1 + k2 + m1 + m2 = c1 = 202
k2 + k3 + m2 + m3 = c2 = 206
k3 + k1(qui prend la place de 'k4' qui n'existe pas) + m3 + k1(qui prend
la place du caractère 'm4' qui n'existe pas) = c3 = 204
Ici, vous est-il possible de faire une attaque à clair pour trouver la
clef manquante?
? ? ? = clef
51 52 53 = texte clair
249 281 216 = chiffré
? ? ? = clef
51 52 53 = texte clair
249 281 206 = chiffré
? ? ? = clef
51 52 53 = texte clair
249 281 206 = chiffré
? ? ? = clef
51 52 53 = texte clair
249 281 206 = chiffré
Et tout en essayant, dans la mesure du possible, d'utiliser des
calculs
simples pour que plus de gens puissent suivre et participer. Je dirais
peut-être à la limite utiliser l'algèbre du niveau secondaire.
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Rien que le recours à l'algèbre
linéaire permet d'aller très vite dans les calculs et les théories.
On aura beau édulcorer cela, les algorithmes et la logique sont d'un
niveau supérieur au secondaire. Je te réponds en simplifiant, quite à
sacrifier la rigueur, afin que je puisse être compris. Néamoins, ma
démarche s'appuie sur un autre niveau que le secondaire.
Alors que tu écris 20 lignes, j'en écris une seule.
Bien entendu la chaîne généré ne doit pas
être plus courte que la clef elle-même puisqu'il y aurait plus d'une
clef qui donnerait le même résultat. Je pense qu'il pourrait être
possible que la même chaîne ou la même sous-clef générée ne puisse
être générée par une clef différente et que de ce fait aucune
collision ne soit possible dans ce sens. Faudrait que je teste cela en
programmation dans l'exemple d'une boucle qui génère toutes les clefs
possibles en 32 bits par exemple.
Ce que tu demandes est une fonction injective : de deux éléments
distincts de départ, tu arrives à deux éléments distincts à
l'arrivée. Cela nécessite un espace d'arrivé au moins aussi "grand"
(cardinal) que l'espace de départ.
Ce n'est pas non plus indispensable à la robustesse de l'algorithme en
lui-même.C1 + C2 = M1 + K + M2 + K
Donc : C1 + C2 = M1 + M2
Je pense que ce dernier exemple (C1 + C2 = M1 + M2) fausserait le
résultat, dans le sens que je ne crois pas que l'algèbre permette
l'annulation de K ici:
1- puisque la valeur de K n'est pas connue.
Soient A, B et C trois variables dont la valeur est connue.
Soit K une variable inconnue.
D'un côté : A+B+K
De l'autre : C+K
Si on soustrait l'un à l'autre : A+B+K - C+K
On a : A+B-C.
K n'est pas connu et a pu être annulé.
2- puisque sur un même côté
du signe '=' 'il faudrait que l'une des deux variables K soit négative et
l'autre positive
Pas au sens de l'arithmétique modulaire (aux spécialistes de rectifier
si nécessaire). Nous alons être en "modulo 10", histoire de simplifier.
5 + 2 = 7
1 + 1 = 2
5 + 7 = 2
D'où vient le "2" du "5+7" ? C'est que 5+7 donne 12, auquel on retire 10
pour rester dans l'intervale [0;10[
Et là, ça se corse :
7 + 7 = 4
4 + 3 = 7
Faire "+3" est le contraire de faire "+7".
3- puisqu'il faudrait qu'il y ait de chaque côté du
signe '=' un pôle identique de K, soit positif ou soit négatif.
Le XOR, bit à bit :
0+0=0
0+1=1
1+0=1
1+1=0
Les trois premières lignes vont d'elles-même. La quatrième ? 1+1 (un
plus un font deux, noté 10 en binaire) dont on ne garde que le chiffre
des unités, soit 0. Il s'agit d'une addition en complément à 1.
En regardant bien, tu vois qu'un xor appliqué deux fois s'annule :
Soit a un bit (valant 0 ou 1), le xor est noté "+".
(a+1)+1=a
(a+0)+0=a
La double application d'un xor s'annule. Voir "rot13" pour un bon exemple.
Par contre on peut trouver la valeur de K en connaissant les valeurs de
M1, M2, C1 et C2 (donc avec une même clef chiffrant deux clairs
différents).
C'est même plus rapide. On peut connaître K rien qu'avec un seul M et un
seul C.
C1 = M1 + K (exemple: 7 = 4 + 3 )
C2 = M2 + K (exemple: 11 = 8 + 3 )
K = C1 - M1, ou bien, K = C2 - M2
C'est un peu long à approcher, mais la clé peut être annulée par ce
type de procédé. Donc, on connaît une donnée supplémentaire "M1 +
M2", en très gros,
M1 chiffré avec M2.
Ici, je ne suis pas certain du raisonnement "M1 chiffré avec M2". Ne
voulez-vous pas dire "M1 et M2 chiffrés ensemble"?
M1 chiffré avec M2, sans remord. Je ne suis pas capable de faire le
développement complet faute de temps. Tu gagneras à étudier le xor.
Juste le xor, c'est déjà 'achement bien.D'une manière générale,
Auriez-vous un petit exemple d'exception qui pourrait s'ajouter au
'simple
algo'?
Aucun. L'utilisation d'une clé de taille retreinte (DSA, RSA, etc...)
expose systématiquement l'algorithme à la force brute avec condition
d'arrêt. C'est juste qu'il faille un temps considérable pour ce faire.
Ok.
comme xor, la réutilisation de la clé ou sa longueur inférieure à
celle du message constitue une faiblesse *grave*. Dans ces conditions,
la cryptanalyse n'est qu'une affaire de temps très court s'il y a
beaucoup de chiffrés d'interceptés, tous conçus avec la même clé.
Tout en connaissent l'algo, à moins d'avoir des répétitions comme les
entêtes.
Non. Les algorithmes utilisés (avec Gnupg, par exemple) sont tous connus,
les mathématiques sous-jacentes maîtrisées, les implémentations sont
libres. En particulier, le code source est disponible à tous.
Et pourtant, le cassage de ces algorithmes n'est pas pour aujourd'hui....
5 - 5 = 0
5 - 6 = 9 ( 5-6=-1, (-1)+10=9 )
5 - 7 = 8
5 - 8 = 7
5 - 9 = 6
La quelle est la bonne ? Chacun des clairs proposés est équiprobable.
En fait, soient C et M un chiffré qu'on connait et M un mot choisi. Il
sera toujour possible de trouver un clé K telle que : C = M + K.
Je ne vois pas très bien comment il est possible dans cet exemple de
trouver le clair sans la clef.
C'est bien ce que je voulais démontrer. Sans la clé, c'est perdu. C'est
le fameux masque jetable, otp, vigenère, xor.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur à
calculer dans la clef afin d'interdire de trouver la clef par une attaque
à clair connue.
Peine perdue.
Dans cette option on suppose longueur de la clef est
toujours à la longueur du clair afin d'éviter les répétitions.
J'essaie de faire le plus simple possible
On a:
49 50 51 = clef
51 52 53 = texte clair
202 206 204 = chiffré
On crypte ainsi:
k1 + k2 + m1 + m2 = c1 = 202
k2 + k3 + m2 + m3 = c2 = 206
k3 + k1(qui prend la place de 'k4' qui n'existe pas) + m3 + k1(qui prend
la place du caractère 'm4' qui n'existe pas) = c3 = 204
je trouve que c3 = 202.
c3Q+49+53+49 2
En lisant le post suivant (tu vas trop vite ;-), je vois que l'erreur est
trouvée...
:-)
Ici, vous est-il possible de faire une attaque à clair pour trouver la
clef manquante?
? ? ? = clef
51 52 53 = texte clair
249 281 216 = chiffré
-->casse([51;52;53],[249;281;216])
ans >
! 44.333333 !
! 101.66667 !
! 74.333333 !
Un peu dur à stocker :-o Quand j'utilise ce résultat pour chiffrer
[51;52;53], je tombe bien sur [249;281;216].
Au final, je n'ai changé qu'un seul paramètre de ma fonction de
déchiffrement. Aucune efficacité supplémentaire, donc.
C'est assez précis comme logiciel! :-)
Et tout en essayant, dans la mesure du possible, d'utiliser des
calculs
simples pour que plus de gens puissent suivre et participer. Je dirais
peut-être à la limite utiliser l'algèbre du niveau secondaire.
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Rien que le recours à l'algèbre
linéaire permet d'aller très vite dans les calculs et les théories.
On aura beau édulcorer cela, les algorithmes et la logique sont d'un
niveau supérieur au secondaire. Je te réponds en simplifiant, quite à
sacrifier la rigueur, afin que je puisse être compris. Néamoins, ma
démarche s'appuie sur un autre niveau que le secondaire.
Alors que tu écris 20 lignes, j'en écris une seule.
Bien entendu la chaîne généré ne doit pas
être plus courte que la clef elle-même puisqu'il y aurait plus d'une
clef qui donnerait le même résultat. Je pense qu'il pourrait être
possible que la même chaîne ou la même sous-clef générée ne puisse
être générée par une clef différente et que de ce fait aucune
collision ne soit possible dans ce sens. Faudrait que je teste cela en
programmation dans l'exemple d'une boucle qui génère toutes les clefs
possibles en 32 bits par exemple.
Ce que tu demandes est une fonction injective : de deux éléments
distincts de départ, tu arrives à deux éléments distincts à
l'arrivée. Cela nécessite un espace d'arrivé au moins aussi "grand"
(cardinal) que l'espace de départ.
Ce n'est pas non plus indispensable à la robustesse de l'algorithme en
lui-même.
C1 + C2 = M1 + K + M2 + K
Donc : C1 + C2 = M1 + M2
Je pense que ce dernier exemple (C1 + C2 = M1 + M2) fausserait le
résultat, dans le sens que je ne crois pas que l'algèbre permette
l'annulation de K ici:
1- puisque la valeur de K n'est pas connue.
Soient A, B et C trois variables dont la valeur est connue.
Soit K une variable inconnue.
D'un côté : A+B+K
De l'autre : C+K
Si on soustrait l'un à l'autre : A+B+K - C+K
On a : A+B-C.
K n'est pas connu et a pu être annulé.
2- puisque sur un même côté
du signe '=' 'il faudrait que l'une des deux variables K soit négative et
l'autre positive
Pas au sens de l'arithmétique modulaire (aux spécialistes de rectifier
si nécessaire). Nous alons être en "modulo 10", histoire de simplifier.
5 + 2 = 7
1 + 1 = 2
5 + 7 = 2
D'où vient le "2" du "5+7" ? C'est que 5+7 donne 12, auquel on retire 10
pour rester dans l'intervale [0;10[
Et là, ça se corse :
7 + 7 = 4
4 + 3 = 7
Faire "+3" est le contraire de faire "+7".
3- puisqu'il faudrait qu'il y ait de chaque côté du
signe '=' un pôle identique de K, soit positif ou soit négatif.
Le XOR, bit à bit :
0+0=0
0+1=1
1+0=1
1+1=0
Les trois premières lignes vont d'elles-même. La quatrième ? 1+1 (un
plus un font deux, noté 10 en binaire) dont on ne garde que le chiffre
des unités, soit 0. Il s'agit d'une addition en complément à 1.
En regardant bien, tu vois qu'un xor appliqué deux fois s'annule :
Soit a un bit (valant 0 ou 1), le xor est noté "+".
(a+1)+1=a
(a+0)+0=a
La double application d'un xor s'annule. Voir "rot13" pour un bon exemple.
Par contre on peut trouver la valeur de K en connaissant les valeurs de
M1, M2, C1 et C2 (donc avec une même clef chiffrant deux clairs
différents).
C'est même plus rapide. On peut connaître K rien qu'avec un seul M et un
seul C.
C1 = M1 + K (exemple: 7 = 4 + 3 )
C2 = M2 + K (exemple: 11 = 8 + 3 )
K = C1 - M1, ou bien, K = C2 - M2
C'est un peu long à approcher, mais la clé peut être annulée par ce
type de procédé. Donc, on connaît une donnée supplémentaire "M1 +
M2", en très gros,
M1 chiffré avec M2.
Ici, je ne suis pas certain du raisonnement "M1 chiffré avec M2". Ne
voulez-vous pas dire "M1 et M2 chiffrés ensemble"?
M1 chiffré avec M2, sans remord. Je ne suis pas capable de faire le
développement complet faute de temps. Tu gagneras à étudier le xor.
Juste le xor, c'est déjà 'achement bien.
D'une manière générale,
Auriez-vous un petit exemple d'exception qui pourrait s'ajouter au
'simple
algo'?
Aucun. L'utilisation d'une clé de taille retreinte (DSA, RSA, etc...)
expose systématiquement l'algorithme à la force brute avec condition
d'arrêt. C'est juste qu'il faille un temps considérable pour ce faire.
Ok.
comme xor, la réutilisation de la clé ou sa longueur inférieure à
celle du message constitue une faiblesse *grave*. Dans ces conditions,
la cryptanalyse n'est qu'une affaire de temps très court s'il y a
beaucoup de chiffrés d'interceptés, tous conçus avec la même clé.
Tout en connaissent l'algo, à moins d'avoir des répétitions comme les
entêtes.
Non. Les algorithmes utilisés (avec Gnupg, par exemple) sont tous connus,
les mathématiques sous-jacentes maîtrisées, les implémentations sont
libres. En particulier, le code source est disponible à tous.
Et pourtant, le cassage de ces algorithmes n'est pas pour aujourd'hui.
...
5 - 5 = 0
5 - 6 = 9 ( 5-6=-1, (-1)+10=9 )
5 - 7 = 8
5 - 8 = 7
5 - 9 = 6
La quelle est la bonne ? Chacun des clairs proposés est équiprobable.
En fait, soient C et M un chiffré qu'on connait et M un mot choisi. Il
sera toujour possible de trouver un clé K telle que : C = M + K.
Je ne vois pas très bien comment il est possible dans cet exemple de
trouver le clair sans la clef.
C'est bien ce que je voulais démontrer. Sans la clé, c'est perdu. C'est
le fameux masque jetable, otp, vigenère, xor.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur à
calculer dans la clef afin d'interdire de trouver la clef par une attaque
à clair connue.
Peine perdue.
Dans cette option on suppose longueur de la clef est
toujours à la longueur du clair afin d'éviter les répétitions.
J'essaie de faire le plus simple possible
On a:
49 50 51 = clef
51 52 53 = texte clair
202 206 204 = chiffré
On crypte ainsi:
k1 + k2 + m1 + m2 = c1 = 202
k2 + k3 + m2 + m3 = c2 = 206
k3 + k1(qui prend la place de 'k4' qui n'existe pas) + m3 + k1(qui prend
la place du caractère 'm4' qui n'existe pas) = c3 = 204
je trouve que c3 = 202.
c3Q+49+53+49 2
En lisant le post suivant (tu vas trop vite ;-), je vois que l'erreur est
trouvée...
:-)
Ici, vous est-il possible de faire une attaque à clair pour trouver la
clef manquante?
? ? ? = clef
51 52 53 = texte clair
249 281 216 = chiffré
-->casse([51;52;53],[249;281;216])
ans >
! 44.333333 !
! 101.66667 !
! 74.333333 !
Un peu dur à stocker :-o Quand j'utilise ce résultat pour chiffrer
[51;52;53], je tombe bien sur [249;281;216].
Au final, je n'ai changé qu'un seul paramètre de ma fonction de
déchiffrement. Aucune efficacité supplémentaire, donc.
C'est assez précis comme logiciel! :-)
Et tout en essayant, dans la mesure du possible, d'utiliser des
calculs
simples pour que plus de gens puissent suivre et participer. Je dirais
peut-être à la limite utiliser l'algèbre du niveau secondaire.
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Rien que le recours à l'algèbre
linéaire permet d'aller très vite dans les calculs et les théories.
On aura beau édulcorer cela, les algorithmes et la logique sont d'un
niveau supérieur au secondaire. Je te réponds en simplifiant, quite à
sacrifier la rigueur, afin que je puisse être compris. Néamoins, ma
démarche s'appuie sur un autre niveau que le secondaire.
Alors que tu écris 20 lignes, j'en écris une seule.
Bien entendu la chaîne généré ne doit pas
être plus courte que la clef elle-même puisqu'il y aurait plus d'une
clef qui donnerait le même résultat. Je pense qu'il pourrait être
possible que la même chaîne ou la même sous-clef générée ne puisse
être générée par une clef différente et que de ce fait aucune
collision ne soit possible dans ce sens. Faudrait que je teste cela en
programmation dans l'exemple d'une boucle qui génère toutes les clefs
possibles en 32 bits par exemple.
Ce que tu demandes est une fonction injective : de deux éléments
distincts de départ, tu arrives à deux éléments distincts à
l'arrivée. Cela nécessite un espace d'arrivé au moins aussi "grand"
(cardinal) que l'espace de départ.
Ce n'est pas non plus indispensable à la robustesse de l'algorithme en
lui-même.C1 + C2 = M1 + K + M2 + K
Donc : C1 + C2 = M1 + M2
Je pense que ce dernier exemple (C1 + C2 = M1 + M2) fausserait le
résultat, dans le sens que je ne crois pas que l'algèbre permette
l'annulation de K ici:
1- puisque la valeur de K n'est pas connue.
Soient A, B et C trois variables dont la valeur est connue.
Soit K une variable inconnue.
D'un côté : A+B+K
De l'autre : C+K
Si on soustrait l'un à l'autre : A+B+K - C+K
On a : A+B-C.
K n'est pas connu et a pu être annulé.
2- puisque sur un même côté
du signe '=' 'il faudrait que l'une des deux variables K soit négative et
l'autre positive
Pas au sens de l'arithmétique modulaire (aux spécialistes de rectifier
si nécessaire). Nous alons être en "modulo 10", histoire de simplifier.
5 + 2 = 7
1 + 1 = 2
5 + 7 = 2
D'où vient le "2" du "5+7" ? C'est que 5+7 donne 12, auquel on retire 10
pour rester dans l'intervale [0;10[
Et là, ça se corse :
7 + 7 = 4
4 + 3 = 7
Faire "+3" est le contraire de faire "+7".
3- puisqu'il faudrait qu'il y ait de chaque côté du
signe '=' un pôle identique de K, soit positif ou soit négatif.
Le XOR, bit à bit :
0+0=0
0+1=1
1+0=1
1+1=0
Les trois premières lignes vont d'elles-même. La quatrième ? 1+1 (un
plus un font deux, noté 10 en binaire) dont on ne garde que le chiffre
des unités, soit 0. Il s'agit d'une addition en complément à 1.
En regardant bien, tu vois qu'un xor appliqué deux fois s'annule :
Soit a un bit (valant 0 ou 1), le xor est noté "+".
(a+1)+1=a
(a+0)+0=a
La double application d'un xor s'annule. Voir "rot13" pour un bon exemple.
Par contre on peut trouver la valeur de K en connaissant les valeurs de
M1, M2, C1 et C2 (donc avec une même clef chiffrant deux clairs
différents).
C'est même plus rapide. On peut connaître K rien qu'avec un seul M et un
seul C.
C1 = M1 + K (exemple: 7 = 4 + 3 )
C2 = M2 + K (exemple: 11 = 8 + 3 )
K = C1 - M1, ou bien, K = C2 - M2
C'est un peu long à approcher, mais la clé peut être annulée par ce
type de procédé. Donc, on connaît une donnée supplémentaire "M1 +
M2", en très gros,
M1 chiffré avec M2.
Ici, je ne suis pas certain du raisonnement "M1 chiffré avec M2". Ne
voulez-vous pas dire "M1 et M2 chiffrés ensemble"?
M1 chiffré avec M2, sans remord. Je ne suis pas capable de faire le
développement complet faute de temps. Tu gagneras à étudier le xor.
Juste le xor, c'est déjà 'achement bien.D'une manière générale,
Auriez-vous un petit exemple d'exception qui pourrait s'ajouter au
'simple
algo'?
Aucun. L'utilisation d'une clé de taille retreinte (DSA, RSA, etc...)
expose systématiquement l'algorithme à la force brute avec condition
d'arrêt. C'est juste qu'il faille un temps considérable pour ce faire.
Ok.
comme xor, la réutilisation de la clé ou sa longueur inférieure à
celle du message constitue une faiblesse *grave*. Dans ces conditions,
la cryptanalyse n'est qu'une affaire de temps très court s'il y a
beaucoup de chiffrés d'interceptés, tous conçus avec la même clé.
Tout en connaissent l'algo, à moins d'avoir des répétitions comme les
entêtes.
Non. Les algorithmes utilisés (avec Gnupg, par exemple) sont tous connus,
les mathématiques sous-jacentes maîtrisées, les implémentations sont
libres. En particulier, le code source est disponible à tous.
Et pourtant, le cassage de ces algorithmes n'est pas pour aujourd'hui....
5 - 5 = 0
5 - 6 = 9 ( 5-6=-1, (-1)+10=9 )
5 - 7 = 8
5 - 8 = 7
5 - 9 = 6
La quelle est la bonne ? Chacun des clairs proposés est équiprobable.
En fait, soient C et M un chiffré qu'on connait et M un mot choisi. Il
sera toujour possible de trouver un clé K telle que : C = M + K.
Je ne vois pas très bien comment il est possible dans cet exemple de
trouver le clair sans la clef.
C'est bien ce que je voulais démontrer. Sans la clé, c'est perdu. C'est
le fameux masque jetable, otp, vigenère, xor.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur à
calculer dans la clef afin d'interdire de trouver la clef par une attaque
à clair connue.
Peine perdue.
Dans cette option on suppose longueur de la clef est
toujours à la longueur du clair afin d'éviter les répétitions.
J'essaie de faire le plus simple possible
On a:
49 50 51 = clef
51 52 53 = texte clair
202 206 204 = chiffré
On crypte ainsi:
k1 + k2 + m1 + m2 = c1 = 202
k2 + k3 + m2 + m3 = c2 = 206
k3 + k1(qui prend la place de 'k4' qui n'existe pas) + m3 + k1(qui prend
la place du caractère 'm4' qui n'existe pas) = c3 = 204
je trouve que c3 = 202.
c3Q+49+53+49 2
En lisant le post suivant (tu vas trop vite ;-), je vois que l'erreur est
trouvée...
:-)
Ici, vous est-il possible de faire une attaque à clair pour trouver la
clef manquante?
? ? ? = clef
51 52 53 = texte clair
249 281 216 = chiffré
-->casse([51;52;53],[249;281;216])
ans >
! 44.333333 !
! 101.66667 !
! 74.333333 !
Un peu dur à stocker :-o Quand j'utilise ce résultat pour chiffrer
[51;52;53], je tombe bien sur [249;281;216].
Au final, je n'ai changé qu'un seul paramètre de ma fonction de
déchiffrement. Aucune efficacité supplémentaire, donc.
C'est assez précis comme logiciel! :-)
? ? ? = clef
51 52 53 = texte clair
249 281 206 = chiffré
Je note que le 216 a été corrigé en 206 :-)
-->casse([51;52;53],[249;281;206])
ans >
! 41. !
! 105. !
! 71. !
? ? ? = clef
51 52 53 = texte clair
249 281 206 = chiffré
Je note que le 216 a été corrigé en 206 :-)
-->casse([51;52;53],[249;281;206])
ans >
! 41. !
! 105. !
! 71. !
? ? ? = clef
51 52 53 = texte clair
249 281 206 = chiffré
Je note que le 216 a été corrigé en 206 :-)
-->casse([51;52;53],[249;281;206])
ans >
! 41. !
! 105. !
! 71. !
Le déchiffrement est défini par :
...
m1 = c1 - c2 + c3 - 2*k1 + k2 - k3
ici que signifie le '-2' ? Car en algèbre ça se définirait ainsi:
m1 = (c1 - c2 + c3 ) - (2*k1) + ( k2 - k3) et de cette façon le résultat
ne correspond pas.
J'ai revérifié mes calculs, ça a l'air pourtant bon. Tu interprètes
bien le sens de la multiplication. les m1, m2 et autres c2 et c3 sont des
nombres (des scalaires, par oppositions aux matrices) qui se multiplient
bien entre eux.
Les M et C sont des vecteurs.
Voici le détail d'un calcul avec M chiffré en C avec la clé K :
C=[8;47;145]
K=[1;2;99]
m1 = c1-c2 +c3 -2*k1+k2-k3
= 8 -47 +145 -2*1 +2 -99
= 7
Au final on/je trouve bien que M=[7;0;45]
Avec:
Le déchiffrement est défini par :
...
m1 = c1 - c2 + c3 - 2*k1 + k2 - k3
ici que signifie le '-2' ? Car en algèbre ça se définirait ainsi:
m1 = (c1 - c2 + c3 ) - (2*k1) + ( k2 - k3) et de cette façon le résultat
ne correspond pas.
J'ai revérifié mes calculs, ça a l'air pourtant bon. Tu interprètes
bien le sens de la multiplication. les m1, m2 et autres c2 et c3 sont des
nombres (des scalaires, par oppositions aux matrices) qui se multiplient
bien entre eux.
Les M et C sont des vecteurs.
Voici le détail d'un calcul avec M chiffré en C avec la clé K :
C=[8;47;145]
K=[1;2;99]
m1 = c1-c2 +c3 -2*k1+k2-k3
= 8 -47 +145 -2*1 +2 -99
= 7
Au final on/je trouve bien que M=[7;0;45]
Avec:
Le déchiffrement est défini par :
...
m1 = c1 - c2 + c3 - 2*k1 + k2 - k3
ici que signifie le '-2' ? Car en algèbre ça se définirait ainsi:
m1 = (c1 - c2 + c3 ) - (2*k1) + ( k2 - k3) et de cette façon le résultat
ne correspond pas.
J'ai revérifié mes calculs, ça a l'air pourtant bon. Tu interprètes
bien le sens de la multiplication. les m1, m2 et autres c2 et c3 sont des
nombres (des scalaires, par oppositions aux matrices) qui se multiplient
bien entre eux.
Les M et C sont des vecteurs.
Voici le détail d'un calcul avec M chiffré en C avec la clé K :
C=[8;47;145]
K=[1;2;99]
m1 = c1-c2 +c3 -2*k1+k2-k3
= 8 -47 +145 -2*1 +2 -99
= 7
Au final on/je trouve bien que M=[7;0;45]
Avec:
Je suis d'accord, car je parlais de l'exemple ci-haut:
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Je suis d'accord, car je parlais de l'exemple ci-haut:
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Je suis d'accord, car je parlais de l'exemple ci-haut:
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Je pense que les calculs de base et l'algèbre sont suffisants pour la
cryptologie puisqu'ils sont la base pour des calculs de niveaux plus élevés.
Avec des calculs plus simples ont a plus d'opérations que des calculs plus
compliqués mais souvent nécessaire pour une meilleure compréhension. C'est
mon point de vue :)
Et via le logiciel Scilab que
vous utilisez pour calculer ça suppose des données à entrer qui ont rapport
avec sa structure de calcul à effectuer.
Est-ce que ce logiciel est gros à installer? Installe-t-il beaucoup de
fichiers dans WindowsXP ?
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur
à
calculer dans la clef afin d'interdire de trouver la clef par une
attaque à clair connue.
Peine perdue.
Parfait. C'était une 'tentative' exprimée avec les mots " AFIN D' ".
Mais, j'y avais pensé que ça pourrait bien être possible. J'aurais
aimé avoir la solution par un exemple en algèbre mais ce n'est pas
grave. Je vais essayer de trouver le calcul algébrique et si je le
trouve, je veux l'ajouter dans mon prochain message avec une nouvelle
tentative 'POUR' empêcher de trouver la clef.
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Je pense que les calculs de base et l'algèbre sont suffisants pour la
cryptologie puisqu'ils sont la base pour des calculs de niveaux plus élevés.
Avec des calculs plus simples ont a plus d'opérations que des calculs plus
compliqués mais souvent nécessaire pour une meilleure compréhension. C'est
mon point de vue :)
Et via le logiciel Scilab que
vous utilisez pour calculer ça suppose des données à entrer qui ont rapport
avec sa structure de calcul à effectuer.
Est-ce que ce logiciel est gros à installer? Installe-t-il beaucoup de
fichiers dans WindowsXP ?
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur
à
calculer dans la clef afin d'interdire de trouver la clef par une
attaque à clair connue.
Peine perdue.
Parfait. C'était une 'tentative' exprimée avec les mots " AFIN D' ".
Mais, j'y avais pensé que ça pourrait bien être possible. J'aurais
aimé avoir la solution par un exemple en algèbre mais ce n'est pas
grave. Je vais essayer de trouver le calcul algébrique et si je le
trouve, je veux l'ajouter dans mon prochain message avec une nouvelle
tentative 'POUR' empêcher de trouver la clef.
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Je pense que les calculs de base et l'algèbre sont suffisants pour la
cryptologie puisqu'ils sont la base pour des calculs de niveaux plus élevés.
Avec des calculs plus simples ont a plus d'opérations que des calculs plus
compliqués mais souvent nécessaire pour une meilleure compréhension. C'est
mon point de vue :)
Et via le logiciel Scilab que
vous utilisez pour calculer ça suppose des données à entrer qui ont rapport
avec sa structure de calcul à effectuer.
Est-ce que ce logiciel est gros à installer? Installe-t-il beaucoup de
fichiers dans WindowsXP ?
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur
à
calculer dans la clef afin d'interdire de trouver la clef par une
attaque à clair connue.
Peine perdue.
Parfait. C'était une 'tentative' exprimée avec les mots " AFIN D' ".
Mais, j'y avais pensé que ça pourrait bien être possible. J'aurais
aimé avoir la solution par un exemple en algèbre mais ce n'est pas
grave. Je vais essayer de trouver le calcul algébrique et si je le
trouve, je veux l'ajouter dans mon prochain message avec une nouvelle
tentative 'POUR' empêcher de trouver la clef.
Bonjour,
On Tue, 4 Jan 2005, Raymond H. wrote:Je suis d'accord, car je parlais de l'exemple ci-haut:
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Tu dis plus loin que tu connais le XOR, mais tu ne parviens pas à passer
de:
C1 + C2 = M1 + K + M2 + K
à
C1 + C2 = M1 + M2
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
Bonjour,
On Tue, 4 Jan 2005, Raymond H. wrote:
Je suis d'accord, car je parlais de l'exemple ci-haut:
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Tu dis plus loin que tu connais le XOR, mais tu ne parviens pas à passer
de:
C1 + C2 = M1 + K + M2 + K
à
C1 + C2 = M1 + M2
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
Bonjour,
On Tue, 4 Jan 2005, Raymond H. wrote:Je suis d'accord, car je parlais de l'exemple ci-haut:
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Tu dis plus loin que tu connais le XOR, mais tu ne parviens pas à passer
de:
C1 + C2 = M1 + K + M2 + K
à
C1 + C2 = M1 + M2
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Je pense que les calculs de base et l'algèbre sont suffisants pour la
cryptologie puisqu'ils sont la base pour des calculs de niveaux plus
élevés.
Avec des calculs plus simples ont a plus d'opérations que des calculs
plus
compliqués mais souvent nécessaire pour une meilleure compréhension.
C'est
mon point de vue :)
Les matheux initiés peuvent lire dans la formule suivante l'intégralité
de ton algorithme. En plus, c'est indépendant de la taille du clair,
chiffré ou de la clé :
C = Mm*M+Mk*K
J'ajoute une sauce du type N-espace vectoriel, endomorphisme, bijection,
déterminant non nul et inversion pour arriver à :
M = inv(Mm)*(C-Mk*K)
qui est le décodage.
Un peu plus loin, et j'arrive à :
K = inv(Mk)*(C-Mm*M)
qui permet de retrouver la clé avec un clair et un chiffré.
Crois-moi sur parole, c'est très rapide. C'est juste qu'il faut
ingurgiter des mathématiques canabissiennes ;-) Le fil de discussion
actuel permet aux étudiants de première année de fac de sciences de
faire des révisions. Pourquoi les en priver ?
Et via le logiciel Scilab que
vous utilisez pour calculer ça suppose des données à entrer qui ont
rapport
avec sa structure de calcul à effectuer.
Tout à fait. La différence entre la version un et deux de ton
algorithme est un changement de valeur de l'une des matrices de passage,
Mk. Le programme est donné à la fin de l'article.Est-ce que ce logiciel est gros à installer? Installe-t-il beaucoup de
fichiers dans WindowsXP ?
Il marche sous MsWindows et pèse 11Mo à peu près, Je ne sais pas ce
qu'il installe comme fichier sous MsWindows, et je ne l'ai pas essayé sur
ce système d'exploitation.C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Se reporter à la réponse d'Erwann pour comprendre ce que je voulais
dire.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur
à
calculer dans la clef afin d'interdire de trouver la clef par une
attaque à clair connue.
Peine perdue.
Parfait. C'était une 'tentative' exprimée avec les mots " AFIN D' ".
Mais, j'y avais pensé que ça pourrait bien être possible. J'aurais
aimé avoir la solution par un exemple en algèbre mais ce n'est pas
grave. Je vais essayer de trouver le calcul algébrique et si je le
trouve, je veux l'ajouter dans mon prochain message avec une nouvelle
tentative 'POUR' empêcher de trouver la clef.
J'ai quand même une disponibilité limitée. C'est long de passer par des
systèmes d'équations linéaires qu'il faut ensuite inverser à la main.
C'est beaucoup plus rapide et fiable de le faire par l'algèbre
matricielle.
Ok.
Voici le programme en question sous scilab. Note bien que je livre le
"code source" afin de donner la possibilité à tous les lecteurs de juger
par eux-même. La force de mes "attaques" réside uniquement dans les
mathématiques, pas dans la fermeture du code source.
Et si je ne t'avais pas communiqué ce que j'utilise pour percer ta
méthode de calcul ? Coup d'bol, j'suis gentil :
// Mm=[1 1 0;0 1 1;0 0 1] ; Mk=[1 0 0;0 1 0;1 0 1] 1ère version
Mm=[1 1 0;0 1 1;0 0 1] ; Mk=[1 1 0;0 1 1;2 0 1]
function [C]=chiffre(_M,_K)
// C est le chiffré de M par la clé K
C = Mm*_M + Mk*_K
endfunction
function [M]Þchiffre(_C,_K)
// M est le déchiffré de C par la clé K
invMm=inv(Mm)
M = invMm*_C - invMm*Mk*_K
endfunction
function [K]Êsse(_M,_C)
// K est la clé ayant servi à partir de M à générer C
K = inv(Mk)*(_C-Mm*_M)
endfunction
Merci
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Je pense que les calculs de base et l'algèbre sont suffisants pour la
cryptologie puisqu'ils sont la base pour des calculs de niveaux plus
élevés.
Avec des calculs plus simples ont a plus d'opérations que des calculs
plus
compliqués mais souvent nécessaire pour une meilleure compréhension.
C'est
mon point de vue :)
Les matheux initiés peuvent lire dans la formule suivante l'intégralité
de ton algorithme. En plus, c'est indépendant de la taille du clair,
chiffré ou de la clé :
C = Mm*M+Mk*K
J'ajoute une sauce du type N-espace vectoriel, endomorphisme, bijection,
déterminant non nul et inversion pour arriver à :
M = inv(Mm)*(C-Mk*K)
qui est le décodage.
Un peu plus loin, et j'arrive à :
K = inv(Mk)*(C-Mm*M)
qui permet de retrouver la clé avec un clair et un chiffré.
Crois-moi sur parole, c'est très rapide. C'est juste qu'il faut
ingurgiter des mathématiques canabissiennes ;-) Le fil de discussion
actuel permet aux étudiants de première année de fac de sciences de
faire des révisions. Pourquoi les en priver ?
Et via le logiciel Scilab que
vous utilisez pour calculer ça suppose des données à entrer qui ont
rapport
avec sa structure de calcul à effectuer.
Tout à fait. La différence entre la version un et deux de ton
algorithme est un changement de valeur de l'une des matrices de passage,
Mk. Le programme est donné à la fin de l'article.
Est-ce que ce logiciel est gros à installer? Installe-t-il beaucoup de
fichiers dans WindowsXP ?
Il marche sous MsWindows et pèse 11Mo à peu près, Je ne sais pas ce
qu'il installe comme fichier sous MsWindows, et je ne l'ai pas essayé sur
ce système d'exploitation.
C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Se reporter à la réponse d'Erwann pour comprendre ce que je voulais
dire.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur
à
calculer dans la clef afin d'interdire de trouver la clef par une
attaque à clair connue.
Peine perdue.
Parfait. C'était une 'tentative' exprimée avec les mots " AFIN D' ".
Mais, j'y avais pensé que ça pourrait bien être possible. J'aurais
aimé avoir la solution par un exemple en algèbre mais ce n'est pas
grave. Je vais essayer de trouver le calcul algébrique et si je le
trouve, je veux l'ajouter dans mon prochain message avec une nouvelle
tentative 'POUR' empêcher de trouver la clef.
J'ai quand même une disponibilité limitée. C'est long de passer par des
systèmes d'équations linéaires qu'il faut ensuite inverser à la main.
C'est beaucoup plus rapide et fiable de le faire par l'algèbre
matricielle.
Ok.
Voici le programme en question sous scilab. Note bien que je livre le
"code source" afin de donner la possibilité à tous les lecteurs de juger
par eux-même. La force de mes "attaques" réside uniquement dans les
mathématiques, pas dans la fermeture du code source.
Et si je ne t'avais pas communiqué ce que j'utilise pour percer ta
méthode de calcul ? Coup d'bol, j'suis gentil :
// Mm=[1 1 0;0 1 1;0 0 1] ; Mk=[1 0 0;0 1 0;1 0 1] 1ère version
Mm=[1 1 0;0 1 1;0 0 1] ; Mk=[1 1 0;0 1 1;2 0 1]
function [C]=chiffre(_M,_K)
// C est le chiffré de M par la clé K
C = Mm*_M + Mk*_K
endfunction
function [M]Þchiffre(_C,_K)
// M est le déchiffré de C par la clé K
invMm=inv(Mm)
M = invMm*_C - invMm*Mk*_K
endfunction
function [K]Êsse(_M,_C)
// K est la clé ayant servi à partir de M à générer C
K = inv(Mk)*(_C-Mm*_M)
endfunction
Merci
C'est une erreur. La cryptologie est une science nécessitant des
mathématique d'un certain niveau.
Je pense que les calculs de base et l'algèbre sont suffisants pour la
cryptologie puisqu'ils sont la base pour des calculs de niveaux plus
élevés.
Avec des calculs plus simples ont a plus d'opérations que des calculs
plus
compliqués mais souvent nécessaire pour une meilleure compréhension.
C'est
mon point de vue :)
Les matheux initiés peuvent lire dans la formule suivante l'intégralité
de ton algorithme. En plus, c'est indépendant de la taille du clair,
chiffré ou de la clé :
C = Mm*M+Mk*K
J'ajoute une sauce du type N-espace vectoriel, endomorphisme, bijection,
déterminant non nul et inversion pour arriver à :
M = inv(Mm)*(C-Mk*K)
qui est le décodage.
Un peu plus loin, et j'arrive à :
K = inv(Mk)*(C-Mm*M)
qui permet de retrouver la clé avec un clair et un chiffré.
Crois-moi sur parole, c'est très rapide. C'est juste qu'il faut
ingurgiter des mathématiques canabissiennes ;-) Le fil de discussion
actuel permet aux étudiants de première année de fac de sciences de
faire des révisions. Pourquoi les en priver ?
Et via le logiciel Scilab que
vous utilisez pour calculer ça suppose des données à entrer qui ont
rapport
avec sa structure de calcul à effectuer.
Tout à fait. La différence entre la version un et deux de ton
algorithme est un changement de valeur de l'une des matrices de passage,
Mk. Le programme est donné à la fin de l'article.Est-ce que ce logiciel est gros à installer? Installe-t-il beaucoup de
fichiers dans WindowsXP ?
Il marche sous MsWindows et pèse 11Mo à peu près, Je ne sais pas ce
qu'il installe comme fichier sous MsWindows, et je ne l'ai pas essayé sur
ce système d'exploitation.C1 + C2 = M1 + K + M2 + K
La valeur de K n'est pas connue, donc on ne pourrait pas l'annuler ici.
Se reporter à la réponse d'Erwann pour comprendre ce que je voulais
dire.
...
Je vais maintenant monter d'une étape et ajouter une seule valeur
à
calculer dans la clef afin d'interdire de trouver la clef par une
attaque à clair connue.
Peine perdue.
Parfait. C'était une 'tentative' exprimée avec les mots " AFIN D' ".
Mais, j'y avais pensé que ça pourrait bien être possible. J'aurais
aimé avoir la solution par un exemple en algèbre mais ce n'est pas
grave. Je vais essayer de trouver le calcul algébrique et si je le
trouve, je veux l'ajouter dans mon prochain message avec une nouvelle
tentative 'POUR' empêcher de trouver la clef.
J'ai quand même une disponibilité limitée. C'est long de passer par des
systèmes d'équations linéaires qu'il faut ensuite inverser à la main.
C'est beaucoup plus rapide et fiable de le faire par l'algèbre
matricielle.
Ok.
Voici le programme en question sous scilab. Note bien que je livre le
"code source" afin de donner la possibilité à tous les lecteurs de juger
par eux-même. La force de mes "attaques" réside uniquement dans les
mathématiques, pas dans la fermeture du code source.
Et si je ne t'avais pas communiqué ce que j'utilise pour percer ta
méthode de calcul ? Coup d'bol, j'suis gentil :
// Mm=[1 1 0;0 1 1;0 0 1] ; Mk=[1 0 0;0 1 0;1 0 1] 1ère version
Mm=[1 1 0;0 1 1;0 0 1] ; Mk=[1 1 0;0 1 1;2 0 1]
function [C]=chiffre(_M,_K)
// C est le chiffré de M par la clé K
C = Mm*_M + Mk*_K
endfunction
function [M]Þchiffre(_C,_K)
// M est le déchiffré de C par la clé K
invMm=inv(Mm)
M = invMm*_C - invMm*Mk*_K
endfunction
function [K]Êsse(_M,_C)
// K est la clé ayant servi à partir de M à générer C
K = inv(Mk)*(_C-Mm*_M)
endfunction
Merci
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
c'était déjà clair. Vous confondez les choses. Le signe + ne désigne
pas l'opération XOR mais une valeur ascii puisqu'en base 256 dans la table
des caractères.
Le XOR se calcul à partir des bits (en binaire) et non à partir des
caractères ascii eux-mêmes comme c'est le cas dans notre exemple. Il n'y a
pas de XOR dans notre exemple du 'Simple algo' depuis le début.
On compare
notre exemple avec le XOR seulement en rapport avec le fait qu'il est aussi
difficile que le XOR à déchiffrer (sinon impossible) et le résultat des
données eux-mêmes n'équivaut pas le XOR non plus.
Or, en algèbre C1 + C2 = M1 + K + M2 + K n'est pas comme C1 + C2 = M1 + M2
Donc, 4+5=2+7+3+7 n'équivaut pas à 4+5=2+3
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
c'était déjà clair. Vous confondez les choses. Le signe + ne désigne
pas l'opération XOR mais une valeur ascii puisqu'en base 256 dans la table
des caractères.
Le XOR se calcul à partir des bits (en binaire) et non à partir des
caractères ascii eux-mêmes comme c'est le cas dans notre exemple. Il n'y a
pas de XOR dans notre exemple du 'Simple algo' depuis le début.
On compare
notre exemple avec le XOR seulement en rapport avec le fait qu'il est aussi
difficile que le XOR à déchiffrer (sinon impossible) et le résultat des
données eux-mêmes n'équivaut pas le XOR non plus.
Or, en algèbre C1 + C2 = M1 + K + M2 + K n'est pas comme C1 + C2 = M1 + M2
Donc, 4+5=2+7+3+7 n'équivaut pas à 4+5=2+3
Fais un effort. Ici, '+' désigne l'opération XOR, et quel que soit X,
X + X = 0. C'est plus clair?
Bonjour,
c'était déjà clair. Vous confondez les choses. Le signe + ne désigne
pas l'opération XOR mais une valeur ascii puisqu'en base 256 dans la table
des caractères.
Le XOR se calcul à partir des bits (en binaire) et non à partir des
caractères ascii eux-mêmes comme c'est le cas dans notre exemple. Il n'y a
pas de XOR dans notre exemple du 'Simple algo' depuis le début.
On compare
notre exemple avec le XOR seulement en rapport avec le fait qu'il est aussi
difficile que le XOR à déchiffrer (sinon impossible) et le résultat des
données eux-mêmes n'équivaut pas le XOR non plus.
Or, en algèbre C1 + C2 = M1 + K + M2 + K n'est pas comme C1 + C2 = M1 + M2
Donc, 4+5=2+7+3+7 n'équivaut pas à 4+5=2+3
