Bonjour Mister Jack,c1[0] = k1[0]^ k2[0] ^ m1[0] ^ m2[0] ^ k2[0] ^ k1[0]
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
Juste une question. Pourquoi remplacez-vous les '+' de la ligne
suivante par des 'xor'? Puisque ça ne fait pas le même calcul ni ne donne
le même résultat. Ce pourrait-il que vous pensez que les '+' sont des 'xor'
ici?
Bonjour Mister Jack,
c1[0] = k1[0]^ k2[0] ^ m1[0] ^ m2[0] ^ k2[0] ^ k1[0]
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
Juste une question. Pourquoi remplacez-vous les '+' de la ligne
suivante par des 'xor'? Puisque ça ne fait pas le même calcul ni ne donne
le même résultat. Ce pourrait-il que vous pensez que les '+' sont des 'xor'
ici?
Bonjour Mister Jack,c1[0] = k1[0]^ k2[0] ^ m1[0] ^ m2[0] ^ k2[0] ^ k1[0]
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
Juste une question. Pourquoi remplacez-vous les '+' de la ligne
suivante par des 'xor'? Puisque ça ne fait pas le même calcul ni ne donne
le même résultat. Ce pourrait-il que vous pensez que les '+' sont des 'xor'
ici?
expliqué plus haut fonctionne avec le 'Simple algo' de l'étape 3 qu'on
a pas réussi encore à casser.
Je l'ai fait. J'ai fourni plusieurs clés correspondant à ton clair et
ton chiffré. Avec UN clair et UN chiffré, j'ai trouvé des TAS de clés.
Effectivement, le problème, c'est que de nombreuses clés vont donner le
même chiffré.
C'est justement ce qu'il faut. Il faut qu'il y ait un grand nombre de
clefs possibles. Plus il y en a, plus c'est difficile à trouver.
De plus,
vous ne tenez pas compte du fait que ce n'est pas seulement la clef qu'il
vous aurait fallu trouver mais le clair aussi; et cela vous ne l'avez pas
fait.
Donc, vos 640 possibilité se sont rien à côté de vrai nombre de
possibilité pour trouve non seulement la clef mais le clair aussi. Car
l'exemple en question, le clair et le chiffré étaient connu. Alors, quelle
est la nécessité de trouver la clef de session si vous avez déjà le clair?
...
Donc, ce n'est pas une clef qui correspond au clair qu'il faudrait
rechercher, mais ce serait plutôt une clef et son clair qui
correspondent au chiffré.
16 : K={1,5,213,45}
...
640 : K={198,197,213,45}
* clés déjà données par Henry.
Aucune des clefs que Henry a présentées n'est la bonne. Elle ne
se
trouve pas non plus dans les 17 choix que vous mentionnez ici.
Je ne
dis pas qu'elle ne fait pas partie des 640. Mais il semble que vous ne
comprenez pas bien la logique de l'algo, car l'exemple que j'ai donné
et que vous faites référence est un exemple dont j'ai donné le clair
et son chiffré; le clair comportait seulement 3 caractères. Imaginez
si le clair avait quelques phrases, donc au dessus de 1000 caractères.
Si vous voulez, faites le test et dites combien de clefs seraient
possible avec un clair de 1000 caractères (ce n'est que quelques
phrases). Je dis ceci mais ce que j'aimerais que vous compreniez c'est
que tout cela ne donne rien d'essayer toutes les clefs pour voir s'il y
en a une qui correspond au clair déjà donné avec son chiffré.
décrypter d'autres fichiers chiffrés. Alors, 'Non'! Car la clef de
session que vous essayez de trouver n'est générée qu'une seule fois,
même si vous écrivez toujours votre phrase de passe (la clef
personnelle que vous tapez). Ceci, en lisant votre réponse à mon
explication, j'ai vu que vous ne l'avez pas compris ni Henry.
La clef que vous écrivez (la phrase de passe) n'est pas utilisée
pour
crypter les données d'un fichier. Le calcul de la phrase de passe qui
est effectué pour générer le code d'indentification n'est pas
inversible (je n'ai pas donné ce calcul encore); donc, vous ne pourriez
pas trouver la phrase de passe car elle n'est pas enregistrée et ne
parait à nul part dans le chiffré du fichier.
...
La seule façon de trouver la phrase de passe (votre clef
personnelle
écrite) est de tenter une attaque forcé (taper plusieurs clefs à
l'endroit prévue à cet effet dans le logiciel jusqu'à ce que vous
écriviez la bonne, et ceci peut être tenté dans n'importe lequel des
logiciels de chiffrage: j'explique pour ceux qui lisent et ne
comprennent pas).
...
alors vos 640 possibilités de clefs de session différentes ne
suffiront pas puisqu'il y en aurait une tonne à essayer. Et c'est pour
cela que Henry a dit: "ça n'a pas de sens.", car il a dit cela pour le
2e exemple qui ne comportait pas la clef ni le clair, et pourtant le
clair à trouver ne comportait que 3 caractères non dévoilés.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
...
Je vous encouragerais à relire attentivement mes explications dans
mon
message précédent et qui sont assez claires pour être comprises
puisque j'ai aussi mis un exemple expliqué pas à pas.
expliqué plus haut fonctionne avec le 'Simple algo' de l'étape 3 qu'on
a pas réussi encore à casser.
Je l'ai fait. J'ai fourni plusieurs clés correspondant à ton clair et
ton chiffré. Avec UN clair et UN chiffré, j'ai trouvé des TAS de clés.
Effectivement, le problème, c'est que de nombreuses clés vont donner le
même chiffré.
C'est justement ce qu'il faut. Il faut qu'il y ait un grand nombre de
clefs possibles. Plus il y en a, plus c'est difficile à trouver.
De plus,
vous ne tenez pas compte du fait que ce n'est pas seulement la clef qu'il
vous aurait fallu trouver mais le clair aussi; et cela vous ne l'avez pas
fait.
Donc, vos 640 possibilité se sont rien à côté de vrai nombre de
possibilité pour trouve non seulement la clef mais le clair aussi. Car
l'exemple en question, le clair et le chiffré étaient connu. Alors, quelle
est la nécessité de trouver la clef de session si vous avez déjà le clair?
...
Donc, ce n'est pas une clef qui correspond au clair qu'il faudrait
rechercher, mais ce serait plutôt une clef et son clair qui
correspondent au chiffré.
16 : K={1,5,213,45}
...
640 : K={198,197,213,45}
* clés déjà données par Henry.
Aucune des clefs que Henry a présentées n'est la bonne. Elle ne
se
trouve pas non plus dans les 17 choix que vous mentionnez ici.
Je ne
dis pas qu'elle ne fait pas partie des 640. Mais il semble que vous ne
comprenez pas bien la logique de l'algo, car l'exemple que j'ai donné
et que vous faites référence est un exemple dont j'ai donné le clair
et son chiffré; le clair comportait seulement 3 caractères. Imaginez
si le clair avait quelques phrases, donc au dessus de 1000 caractères.
Si vous voulez, faites le test et dites combien de clefs seraient
possible avec un clair de 1000 caractères (ce n'est que quelques
phrases). Je dis ceci mais ce que j'aimerais que vous compreniez c'est
que tout cela ne donne rien d'essayer toutes les clefs pour voir s'il y
en a une qui correspond au clair déjà donné avec son chiffré.
décrypter d'autres fichiers chiffrés. Alors, 'Non'! Car la clef de
session que vous essayez de trouver n'est générée qu'une seule fois,
même si vous écrivez toujours votre phrase de passe (la clef
personnelle que vous tapez). Ceci, en lisant votre réponse à mon
explication, j'ai vu que vous ne l'avez pas compris ni Henry.
La clef que vous écrivez (la phrase de passe) n'est pas utilisée
pour
crypter les données d'un fichier. Le calcul de la phrase de passe qui
est effectué pour générer le code d'indentification n'est pas
inversible (je n'ai pas donné ce calcul encore); donc, vous ne pourriez
pas trouver la phrase de passe car elle n'est pas enregistrée et ne
parait à nul part dans le chiffré du fichier.
...
La seule façon de trouver la phrase de passe (votre clef
personnelle
écrite) est de tenter une attaque forcé (taper plusieurs clefs à
l'endroit prévue à cet effet dans le logiciel jusqu'à ce que vous
écriviez la bonne, et ceci peut être tenté dans n'importe lequel des
logiciels de chiffrage: j'explique pour ceux qui lisent et ne
comprennent pas).
...
alors vos 640 possibilités de clefs de session différentes ne
suffiront pas puisqu'il y en aurait une tonne à essayer. Et c'est pour
cela que Henry a dit: "ça n'a pas de sens.", car il a dit cela pour le
2e exemple qui ne comportait pas la clef ni le clair, et pourtant le
clair à trouver ne comportait que 3 caractères non dévoilés.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
...
Je vous encouragerais à relire attentivement mes explications dans
mon
message précédent et qui sont assez claires pour être comprises
puisque j'ai aussi mis un exemple expliqué pas à pas.
expliqué plus haut fonctionne avec le 'Simple algo' de l'étape 3 qu'on
a pas réussi encore à casser.
Je l'ai fait. J'ai fourni plusieurs clés correspondant à ton clair et
ton chiffré. Avec UN clair et UN chiffré, j'ai trouvé des TAS de clés.
Effectivement, le problème, c'est que de nombreuses clés vont donner le
même chiffré.
C'est justement ce qu'il faut. Il faut qu'il y ait un grand nombre de
clefs possibles. Plus il y en a, plus c'est difficile à trouver.
De plus,
vous ne tenez pas compte du fait que ce n'est pas seulement la clef qu'il
vous aurait fallu trouver mais le clair aussi; et cela vous ne l'avez pas
fait.
Donc, vos 640 possibilité se sont rien à côté de vrai nombre de
possibilité pour trouve non seulement la clef mais le clair aussi. Car
l'exemple en question, le clair et le chiffré étaient connu. Alors, quelle
est la nécessité de trouver la clef de session si vous avez déjà le clair?
...
Donc, ce n'est pas une clef qui correspond au clair qu'il faudrait
rechercher, mais ce serait plutôt une clef et son clair qui
correspondent au chiffré.
16 : K={1,5,213,45}
...
640 : K={198,197,213,45}
* clés déjà données par Henry.
Aucune des clefs que Henry a présentées n'est la bonne. Elle ne
se
trouve pas non plus dans les 17 choix que vous mentionnez ici.
Je ne
dis pas qu'elle ne fait pas partie des 640. Mais il semble que vous ne
comprenez pas bien la logique de l'algo, car l'exemple que j'ai donné
et que vous faites référence est un exemple dont j'ai donné le clair
et son chiffré; le clair comportait seulement 3 caractères. Imaginez
si le clair avait quelques phrases, donc au dessus de 1000 caractères.
Si vous voulez, faites le test et dites combien de clefs seraient
possible avec un clair de 1000 caractères (ce n'est que quelques
phrases). Je dis ceci mais ce que j'aimerais que vous compreniez c'est
que tout cela ne donne rien d'essayer toutes les clefs pour voir s'il y
en a une qui correspond au clair déjà donné avec son chiffré.
décrypter d'autres fichiers chiffrés. Alors, 'Non'! Car la clef de
session que vous essayez de trouver n'est générée qu'une seule fois,
même si vous écrivez toujours votre phrase de passe (la clef
personnelle que vous tapez). Ceci, en lisant votre réponse à mon
explication, j'ai vu que vous ne l'avez pas compris ni Henry.
La clef que vous écrivez (la phrase de passe) n'est pas utilisée
pour
crypter les données d'un fichier. Le calcul de la phrase de passe qui
est effectué pour générer le code d'indentification n'est pas
inversible (je n'ai pas donné ce calcul encore); donc, vous ne pourriez
pas trouver la phrase de passe car elle n'est pas enregistrée et ne
parait à nul part dans le chiffré du fichier.
...
La seule façon de trouver la phrase de passe (votre clef
personnelle
écrite) est de tenter une attaque forcé (taper plusieurs clefs à
l'endroit prévue à cet effet dans le logiciel jusqu'à ce que vous
écriviez la bonne, et ceci peut être tenté dans n'importe lequel des
logiciels de chiffrage: j'explique pour ceux qui lisent et ne
comprennent pas).
...
alors vos 640 possibilités de clefs de session différentes ne
suffiront pas puisqu'il y en aurait une tonne à essayer. Et c'est pour
cela que Henry a dit: "ça n'a pas de sens.", car il a dit cela pour le
2e exemple qui ne comportait pas la clef ni le clair, et pourtant le
clair à trouver ne comportait que 3 caractères non dévoilés.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
...
Je vous encouragerais à relire attentivement mes explications dans
mon
message précédent et qui sont assez claires pour être comprises
puisque j'ai aussi mis un exemple expliqué pas à pas.
en binaire, quand vous faîtes ab+cdï,
on a f = b^d, et e = a^c^(b.d)
en binaire, quand vous faîtes ab+cdï,
on a f = b^d, et e = a^c^(b.d)
en binaire, quand vous faîtes ab+cdï,
on a f = b^d, et e = a^c^(b.d)
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
On se retrouve avec un simple XOR où la clé n'intervient pas.
Le premier bit du chiffré est ainsi fonction uniquement du clair.
Bon, sinon on a déjà 1 bit sur 8 d'inexploité par la clé
Je ne crois pas, dans le cas général. Si changer k1[0] ne change pas
c1[0], une retenue pourra se propager et perturber c1.
Contre-exemple :
M = [8;12;21]
K = [7;8;9;10]
-->SAxor(M,K)
! 50 !
! 67 !
! 65 !
-->SAxor(M,K+[-1;0;0;0])
! 48 !
! 67 !
! 65 !
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
On se retrouve avec un simple XOR où la clé n'intervient pas.
Le premier bit du chiffré est ainsi fonction uniquement du clair.
Bon, sinon on a déjà 1 bit sur 8 d'inexploité par la clé
Je ne crois pas, dans le cas général. Si changer k1[0] ne change pas
c1[0], une retenue pourra se propager et perturber c1.
Contre-exemple :
M = [8;12;21]
K = [7;8;9;10]
-->SAxor(M,K)
! 50 !
! 67 !
! 65 !
-->SAxor(M,K+[-1;0;0;0])
! 48 !
! 67 !
! 65 !
On peut donc simplifier en : c1[0] = m1[0] ^ m2[0].
On se retrouve avec un simple XOR où la clé n'intervient pas.
Le premier bit du chiffré est ainsi fonction uniquement du clair.
Bon, sinon on a déjà 1 bit sur 8 d'inexploité par la clé
Je ne crois pas, dans le cas général. Si changer k1[0] ne change pas
c1[0], une retenue pourra se propager et perturber c1.
Contre-exemple :
M = [8;12;21]
K = [7;8;9;10]
-->SAxor(M,K)
! 50 !
! 67 !
! 65 !
-->SAxor(M,K+[-1;0;0;0])
! 48 !
! 67 !
! 65 !
en binaire, quand vous faîtes ab+cdï,
on a f = b^d, et e = a^c^(b.d)
T'as l'air de t'y connaitre ;-) T'aurais pas dès fois la formule
complète pour 8 bits ? Ces foutues retenues me retiennent péniblement.
en binaire, quand vous faîtes ab+cdï,
on a f = b^d, et e = a^c^(b.d)
T'as l'air de t'y connaitre ;-) T'aurais pas dès fois la formule
complète pour 8 bits ? Ces foutues retenues me retiennent péniblement.
en binaire, quand vous faîtes ab+cdï,
on a f = b^d, et e = a^c^(b.d)
T'as l'air de t'y connaitre ;-) T'aurais pas dès fois la formule
complète pour 8 bits ? Ces foutues retenues me retiennent péniblement.
T'as l'air de t'y connaitre ;-) T'aurais pas dès fois la formule
complète pour 8 bits ? Ces foutues retenues me retiennent péniblement.
Bah, c'est relativement simple quand on peut faire référnce à une
'retenue', mais formaliser directement le 8ème bit résultat en fonction
de l'ensemble des données présentées, c'est *très* long.
c0 ^b0
c1¡^b1^a0.b0
c2=((!((a0.b0.a1)+(a1.b1)+(a0.b0.b1)).((!(b2).a2)+(!(a2).b2)))
+(!(((!(b2).a2).(!(a2).b2))).((a0.b0.a1)+(a1.b1)+(a0.b0.b1))))
Je pense que certains logiciels de modélisation en VHDL devraient être
capables de sortir un design en portes NOT, AND et OR à partir d'une
simple addition 8 bits. Ca pourrait aider éventuellement.
T'as l'air de t'y connaitre ;-) T'aurais pas dès fois la formule
complète pour 8 bits ? Ces foutues retenues me retiennent péniblement.
Bah, c'est relativement simple quand on peut faire référnce à une
'retenue', mais formaliser directement le 8ème bit résultat en fonction
de l'ensemble des données présentées, c'est *très* long.
c0 ^b0
c1¡^b1^a0.b0
c2=((!((a0.b0.a1)+(a1.b1)+(a0.b0.b1)).((!(b2).a2)+(!(a2).b2)))
+(!(((!(b2).a2).(!(a2).b2))).((a0.b0.a1)+(a1.b1)+(a0.b0.b1))))
Je pense que certains logiciels de modélisation en VHDL devraient être
capables de sortir un design en portes NOT, AND et OR à partir d'une
simple addition 8 bits. Ca pourrait aider éventuellement.
T'as l'air de t'y connaitre ;-) T'aurais pas dès fois la formule
complète pour 8 bits ? Ces foutues retenues me retiennent péniblement.
Bah, c'est relativement simple quand on peut faire référnce à une
'retenue', mais formaliser directement le 8ème bit résultat en fonction
de l'ensemble des données présentées, c'est *très* long.
c0 ^b0
c1¡^b1^a0.b0
c2=((!((a0.b0.a1)+(a1.b1)+(a0.b0.b1)).((!(b2).a2)+(!(a2).b2)))
+(!(((!(b2).a2).(!(a2).b2))).((a0.b0.a1)+(a1.b1)+(a0.b0.b1))))
Je pense que certains logiciels de modélisation en VHDL devraient être
capables de sortir un design en portes NOT, AND et OR à partir d'une
simple addition 8 bits. Ca pourrait aider éventuellement.
Effectivement, le problème, c'est que de nombreuses clés vont donner le
même chiffré.
C'est justement ce qu'il faut. Il faut qu'il y ait un grand nombre
de
clefs possibles. Plus il y en a, plus c'est difficile à trouver.
C'est une belle philosophie Schadok.
A quoi ça sert d'agrandir l'espace des clés d'un ordre de grandeur
(dimension) si c'est pour augmenter les clés similaires d'autant.
Avec une clé de même longueur que le clair, la correspondance est
unique. Dès lors que la clé est plus longue que le clair, il existe
systématiquement des clés équivalentes dans la même proportion.
De plus,
vous ne tenez pas compte du fait que ce n'est pas seulement la clef qu'il
vous aurait fallu trouver mais le clair aussi; et cela vous ne l'avez pas
fait.
Là, je reste sur la position que j'avais donné au départ : Avec un
chiffré dont la clé de session (aux contraites qui vont bien :
aléatoire, bien choisie, etc...) n'est utilisée qu'une *unique* fois, je
ne peux strictement rien faire. Si j'ose dire, ni personne ni les maths.
Ce n'est pas que c'est difficile : c'est impossible.
Donc, vos 640 possibilité se sont rien à côté de vrai nombre de
possibilité pour trouve non seulement la clef mais le clair aussi. Car
l'exemple en question, le clair et le chiffré étaient connu. Alors,
quelle
est la nécessité de trouver la clef de session si vous avez déjà le
clair?
En trouvant la clé de session, on peut cryptanalyser la phrase de passe
selon le même processus puisqu'on a maintenant la clé de session
chiffré et la clé de session en clair.
En notation maison, ça donne :
M = clair
S = clé de Session
P = prase de Passe
C = Chiffré
{}{} = concaténation
/ = chiffrement
= déchiffrement ou cryptanalyse
C = {M/S}[S/P}
C et M sont connus.
De là : S = MC (c'est ce que je cherche à faire)
Le problème revient donc à trouver S/P avec S connu : la phrase de passe
est au bout.
...
Donc, ce n'est pas une clef qui correspond au clair qu'il faudrait
rechercher, mais ce serait plutôt une clef et son clair qui
correspondent au chiffré.
Tout à fait. Du clair et du chiffré global on trouve la clé de session
clair. Par définition on dispose aussi de la clé de session chiffré. De
là, avec clair et chiffré, on tente de trouver la (une) phrase de passe.
16 : K={1,5,213,45}
...
640 : K={198,197,213,45}
* clés déjà données par Henry.
Aucune des clefs que Henry a présentées n'est la bonne. Elle ne
se
trouve pas non plus dans les 17 choix que vous mentionnez ici.
Ces clés répondent au problème suivant :
M=[8;12;21]
C=[32;51;62]
Avec le procédé utilisant le xor.
Si nous nous sommes trompés, merci de vérifier les calculs suivants :
SAxor([1;2;3],[1;2;3;4])=[5;11;13]
SAxor([255;255;255],[255;255;255;255])=[2;2;2]
SAxor([0;0;0],[255;255;255;255])=[0;0;1]
SAxor([255;255;255],[0;0;0;0])=[254;254;255]
SAxor([8;12;21],[1;5;68;225])=[32;51;62]
...
alors vos 640 possibilités de clefs de session différentes ne
suffiront pas puisqu'il y en aurait une tonne à essayer. Et c'est pour
cela que Henry a dit: "ça n'a pas de sens.", car il a dit cela pour le
2e exemple qui ne comportait pas la clef ni le clair, et pourtant le
clair à trouver ne comportait que 3 caractères non dévoilés.
Je voulais dire qu'à partir d'un chiffré on peut désigner n'importe
quelle clé ou clair pour ensuite retrouver le morceau manquant.
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Même pas mal. J'attends juste les spécifications détaillées, précises
et sans trop de blabla.
Bonne journée.
Effectivement, le problème, c'est que de nombreuses clés vont donner le
même chiffré.
C'est justement ce qu'il faut. Il faut qu'il y ait un grand nombre
de
clefs possibles. Plus il y en a, plus c'est difficile à trouver.
C'est une belle philosophie Schadok.
A quoi ça sert d'agrandir l'espace des clés d'un ordre de grandeur
(dimension) si c'est pour augmenter les clés similaires d'autant.
Avec une clé de même longueur que le clair, la correspondance est
unique. Dès lors que la clé est plus longue que le clair, il existe
systématiquement des clés équivalentes dans la même proportion.
De plus,
vous ne tenez pas compte du fait que ce n'est pas seulement la clef qu'il
vous aurait fallu trouver mais le clair aussi; et cela vous ne l'avez pas
fait.
Là, je reste sur la position que j'avais donné au départ : Avec un
chiffré dont la clé de session (aux contraites qui vont bien :
aléatoire, bien choisie, etc...) n'est utilisée qu'une *unique* fois, je
ne peux strictement rien faire. Si j'ose dire, ni personne ni les maths.
Ce n'est pas que c'est difficile : c'est impossible.
Donc, vos 640 possibilité se sont rien à côté de vrai nombre de
possibilité pour trouve non seulement la clef mais le clair aussi. Car
l'exemple en question, le clair et le chiffré étaient connu. Alors,
quelle
est la nécessité de trouver la clef de session si vous avez déjà le
clair?
En trouvant la clé de session, on peut cryptanalyser la phrase de passe
selon le même processus puisqu'on a maintenant la clé de session
chiffré et la clé de session en clair.
En notation maison, ça donne :
M = clair
S = clé de Session
P = prase de Passe
C = Chiffré
{}{} = concaténation
/ = chiffrement
= déchiffrement ou cryptanalyse
C = {M/S}[S/P}
C et M sont connus.
De là : S = MC (c'est ce que je cherche à faire)
Le problème revient donc à trouver S/P avec S connu : la phrase de passe
est au bout.
...
Donc, ce n'est pas une clef qui correspond au clair qu'il faudrait
rechercher, mais ce serait plutôt une clef et son clair qui
correspondent au chiffré.
Tout à fait. Du clair et du chiffré global on trouve la clé de session
clair. Par définition on dispose aussi de la clé de session chiffré. De
là, avec clair et chiffré, on tente de trouver la (une) phrase de passe.
16 : K={1,5,213,45}
...
640 : K={198,197,213,45}
* clés déjà données par Henry.
Aucune des clefs que Henry a présentées n'est la bonne. Elle ne
se
trouve pas non plus dans les 17 choix que vous mentionnez ici.
Ces clés répondent au problème suivant :
M=[8;12;21]
C=[32;51;62]
Avec le procédé utilisant le xor.
Si nous nous sommes trompés, merci de vérifier les calculs suivants :
SAxor([1;2;3],[1;2;3;4])=[5;11;13]
SAxor([255;255;255],[255;255;255;255])=[2;2;2]
SAxor([0;0;0],[255;255;255;255])=[0;0;1]
SAxor([255;255;255],[0;0;0;0])=[254;254;255]
SAxor([8;12;21],[1;5;68;225])=[32;51;62]
...
alors vos 640 possibilités de clefs de session différentes ne
suffiront pas puisqu'il y en aurait une tonne à essayer. Et c'est pour
cela que Henry a dit: "ça n'a pas de sens.", car il a dit cela pour le
2e exemple qui ne comportait pas la clef ni le clair, et pourtant le
clair à trouver ne comportait que 3 caractères non dévoilés.
Je voulais dire qu'à partir d'un chiffré on peut désigner n'importe
quelle clé ou clair pour ensuite retrouver le morceau manquant.
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Même pas mal. J'attends juste les spécifications détaillées, précises
et sans trop de blabla.
Bonne journée.
Effectivement, le problème, c'est que de nombreuses clés vont donner le
même chiffré.
C'est justement ce qu'il faut. Il faut qu'il y ait un grand nombre
de
clefs possibles. Plus il y en a, plus c'est difficile à trouver.
C'est une belle philosophie Schadok.
A quoi ça sert d'agrandir l'espace des clés d'un ordre de grandeur
(dimension) si c'est pour augmenter les clés similaires d'autant.
Avec une clé de même longueur que le clair, la correspondance est
unique. Dès lors que la clé est plus longue que le clair, il existe
systématiquement des clés équivalentes dans la même proportion.
De plus,
vous ne tenez pas compte du fait que ce n'est pas seulement la clef qu'il
vous aurait fallu trouver mais le clair aussi; et cela vous ne l'avez pas
fait.
Là, je reste sur la position que j'avais donné au départ : Avec un
chiffré dont la clé de session (aux contraites qui vont bien :
aléatoire, bien choisie, etc...) n'est utilisée qu'une *unique* fois, je
ne peux strictement rien faire. Si j'ose dire, ni personne ni les maths.
Ce n'est pas que c'est difficile : c'est impossible.
Donc, vos 640 possibilité se sont rien à côté de vrai nombre de
possibilité pour trouve non seulement la clef mais le clair aussi. Car
l'exemple en question, le clair et le chiffré étaient connu. Alors,
quelle
est la nécessité de trouver la clef de session si vous avez déjà le
clair?
En trouvant la clé de session, on peut cryptanalyser la phrase de passe
selon le même processus puisqu'on a maintenant la clé de session
chiffré et la clé de session en clair.
En notation maison, ça donne :
M = clair
S = clé de Session
P = prase de Passe
C = Chiffré
{}{} = concaténation
/ = chiffrement
= déchiffrement ou cryptanalyse
C = {M/S}[S/P}
C et M sont connus.
De là : S = MC (c'est ce que je cherche à faire)
Le problème revient donc à trouver S/P avec S connu : la phrase de passe
est au bout.
...
Donc, ce n'est pas une clef qui correspond au clair qu'il faudrait
rechercher, mais ce serait plutôt une clef et son clair qui
correspondent au chiffré.
Tout à fait. Du clair et du chiffré global on trouve la clé de session
clair. Par définition on dispose aussi de la clé de session chiffré. De
là, avec clair et chiffré, on tente de trouver la (une) phrase de passe.
16 : K={1,5,213,45}
...
640 : K={198,197,213,45}
* clés déjà données par Henry.
Aucune des clefs que Henry a présentées n'est la bonne. Elle ne
se
trouve pas non plus dans les 17 choix que vous mentionnez ici.
Ces clés répondent au problème suivant :
M=[8;12;21]
C=[32;51;62]
Avec le procédé utilisant le xor.
Si nous nous sommes trompés, merci de vérifier les calculs suivants :
SAxor([1;2;3],[1;2;3;4])=[5;11;13]
SAxor([255;255;255],[255;255;255;255])=[2;2;2]
SAxor([0;0;0],[255;255;255;255])=[0;0;1]
SAxor([255;255;255],[0;0;0;0])=[254;254;255]
SAxor([8;12;21],[1;5;68;225])=[32;51;62]
...
alors vos 640 possibilités de clefs de session différentes ne
suffiront pas puisqu'il y en aurait une tonne à essayer. Et c'est pour
cela que Henry a dit: "ça n'a pas de sens.", car il a dit cela pour le
2e exemple qui ne comportait pas la clef ni le clair, et pourtant le
clair à trouver ne comportait que 3 caractères non dévoilés.
Je voulais dire qu'à partir d'un chiffré on peut désigner n'importe
quelle clé ou clair pour ensuite retrouver le morceau manquant.
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Même pas mal. J'attends juste les spécifications détaillées, précises
et sans trop de blabla.
Bonne journée.
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Mais pas nécessairement le bon clair.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Mais pas nécessairement le bon clair.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Mais pas nécessairement le bon clair.
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Je tiens à remercier 'Christophe HENRY' pour avoir avoué sa limite
actuelle (dans les maths) disant qu'il n'arrive pas casser le 'Simple
algo' à l'étape 3.
Pas de remerciements. C'est normal. Et surtout, ton procédé est
quasi-cryptanalysé. Je souhaite juste en finir avec l'équation triviale
qui me bloque pour obtenir une solution belle et nette comme je les aimes
tant : du genre donner TOUTES les clés possibles plutôt qu'une seule
comme je l'ai fait lorsque tu as passé ta clé sur 4 octets :-*
...
J'aimerais bien qu'un spécialiste en cryptologie ou en mathématique nous
dise son avis sur la possibilité du cassage du 'Simple algo' à l'étape
3.
Marrant de séparer crypto et maths. Autant imaginer un auteur
(ie crypto) de romans français ne parlant (ie maths) pas le français :-/
Certes. Mais tu négliges un GROS détail : les contributeurs du forums
ont derrière eux les centaines d'années de sciences mathématiques dont
ils se servent pour argumenter. Jusqu'à mes démonstrations et
applications qui ont démontré la faiblesse du procédé. Or, si je
m'avère compétent (à ton sens), les autres le sont au moins autant.
Raymond, pourquoi ai-je l'impression que tu implémentes une fonction de
hachage en ce qui concerne nos remarques ?
??? une fonction de hachage!#!!?##? Je ne suis pas sûr de comprendre.
C'est là où je voulais en arriver :
tu n'as pas les connaissances de
base pour construire ce genre d'algorithme dont les termes élémentaires
t'échappent.
Supposons que nous (on dit tous la même chose, donc : nous)
ayons raison. Nous possédons la science nécessaire pour se l'expliquer
entre nous et tout autre personne culturée. Mais tu ne peux pas
comprendre et, c'est le plus génant, accorder de valeur à nos écrits
parce que tu ne les comprends pas. C'est dommage.
...Ces fils sont à la suite justement de l'annonce d'AllCrypter
dans ce groupe de discussion,
Ca s'appelle du SPAM, en violation avec ma petite pensée à moi
que j'ai
sur l'usage des forums, et, en violation avec les chartes régissant la
hiérarchie fr.*.
Tu as d'ailleurs répété l'offense sur au moins un autre forum.
Au lieu de dire : "j'ai un algo qui tue, qui veut me le casser ?", tu as
posté un message à caractère commercial crade.
et mon but est de
développer ce 'Simple algo' en sorte que je le mette ou m'en inspire
pour la version 3 d'AllCrypter. Je tiens à ce que les gens utilisant
AllCrypter ait un logiciel sur lequel ils peuvent compter. C'est
pourquoi je veille à son amélioration POUR une version 3 interdisant
les attaques à clair ou chiffré connue ou d'autres sortes d'attaques.
Moi, j'y crois, et c'est à quoi je mets mon énergie ici.
Tout ce que tu vas arriver à faire c'est épuiser les compétences (dans
mon cas) et les énergies (de tous les contributeurs). Tout cela est fait
gratos, ne l'oublie pas.
L'énergie totale est limitée et tends à
s'épuiser.Je vous assure que j'ai pris en considération plusieurs de vos
remarques, même si je n'en fait pas toujours suite. De plus,
j'apprécie grandement vos contributions dans ce fil (étape 1 et 2, et
celle-ci). Dès le début j'ai apprécié la façon dont vous avez fait
vos interventions, même si la profondeur de vos calculs me laissait
quelque fois un peu derrière :-) Vous êtes même celui qui a le plus
souvent contribué et il est évident que vous n'êtes pas un débutant
en la matière.
Tu vas rire : je suis _débutant_ en la matière.
Ce n'est pas que je sois
modeste, mais juste réaliste. La crypto est pour moi un amusement, pas
mon métier principal. Imagine les autres...
C'est comme si un allemand (parlant très bien l'allemand) te disait
que tu es très fort parce que tu parles français :-o
Je tiens à remercier 'Christophe HENRY' pour avoir avoué sa limite
actuelle (dans les maths) disant qu'il n'arrive pas casser le 'Simple
algo' à l'étape 3.
Pas de remerciements. C'est normal. Et surtout, ton procédé est
quasi-cryptanalysé. Je souhaite juste en finir avec l'équation triviale
qui me bloque pour obtenir une solution belle et nette comme je les aimes
tant : du genre donner TOUTES les clés possibles plutôt qu'une seule
comme je l'ai fait lorsque tu as passé ta clé sur 4 octets :-*
...
J'aimerais bien qu'un spécialiste en cryptologie ou en mathématique nous
dise son avis sur la possibilité du cassage du 'Simple algo' à l'étape
3.
Marrant de séparer crypto et maths. Autant imaginer un auteur
(ie crypto) de romans français ne parlant (ie maths) pas le français :-/
Certes. Mais tu négliges un GROS détail : les contributeurs du forums
ont derrière eux les centaines d'années de sciences mathématiques dont
ils se servent pour argumenter. Jusqu'à mes démonstrations et
applications qui ont démontré la faiblesse du procédé. Or, si je
m'avère compétent (à ton sens), les autres le sont au moins autant.
Raymond, pourquoi ai-je l'impression que tu implémentes une fonction de
hachage en ce qui concerne nos remarques ?
??? une fonction de hachage!#!!?##? Je ne suis pas sûr de comprendre.
C'est là où je voulais en arriver :
tu n'as pas les connaissances de
base pour construire ce genre d'algorithme dont les termes élémentaires
t'échappent.
Supposons que nous (on dit tous la même chose, donc : nous)
ayons raison. Nous possédons la science nécessaire pour se l'expliquer
entre nous et tout autre personne culturée. Mais tu ne peux pas
comprendre et, c'est le plus génant, accorder de valeur à nos écrits
parce que tu ne les comprends pas. C'est dommage.
...Ces fils sont à la suite justement de l'annonce d'AllCrypter
dans ce groupe de discussion,
Ca s'appelle du SPAM, en violation avec ma petite pensée à moi
que j'ai
sur l'usage des forums, et, en violation avec les chartes régissant la
hiérarchie fr.*.
Tu as d'ailleurs répété l'offense sur au moins un autre forum.
Au lieu de dire : "j'ai un algo qui tue, qui veut me le casser ?", tu as
posté un message à caractère commercial crade.
et mon but est de
développer ce 'Simple algo' en sorte que je le mette ou m'en inspire
pour la version 3 d'AllCrypter. Je tiens à ce que les gens utilisant
AllCrypter ait un logiciel sur lequel ils peuvent compter. C'est
pourquoi je veille à son amélioration POUR une version 3 interdisant
les attaques à clair ou chiffré connue ou d'autres sortes d'attaques.
Moi, j'y crois, et c'est à quoi je mets mon énergie ici.
Tout ce que tu vas arriver à faire c'est épuiser les compétences (dans
mon cas) et les énergies (de tous les contributeurs). Tout cela est fait
gratos, ne l'oublie pas.
L'énergie totale est limitée et tends à
s'épuiser.
Je vous assure que j'ai pris en considération plusieurs de vos
remarques, même si je n'en fait pas toujours suite. De plus,
j'apprécie grandement vos contributions dans ce fil (étape 1 et 2, et
celle-ci). Dès le début j'ai apprécié la façon dont vous avez fait
vos interventions, même si la profondeur de vos calculs me laissait
quelque fois un peu derrière :-) Vous êtes même celui qui a le plus
souvent contribué et il est évident que vous n'êtes pas un débutant
en la matière.
Tu vas rire : je suis _débutant_ en la matière.
Ce n'est pas que je sois
modeste, mais juste réaliste. La crypto est pour moi un amusement, pas
mon métier principal. Imagine les autres...
C'est comme si un allemand (parlant très bien l'allemand) te disait
que tu es très fort parce que tu parles français :-o
Je tiens à remercier 'Christophe HENRY' pour avoir avoué sa limite
actuelle (dans les maths) disant qu'il n'arrive pas casser le 'Simple
algo' à l'étape 3.
Pas de remerciements. C'est normal. Et surtout, ton procédé est
quasi-cryptanalysé. Je souhaite juste en finir avec l'équation triviale
qui me bloque pour obtenir une solution belle et nette comme je les aimes
tant : du genre donner TOUTES les clés possibles plutôt qu'une seule
comme je l'ai fait lorsque tu as passé ta clé sur 4 octets :-*
...
J'aimerais bien qu'un spécialiste en cryptologie ou en mathématique nous
dise son avis sur la possibilité du cassage du 'Simple algo' à l'étape
3.
Marrant de séparer crypto et maths. Autant imaginer un auteur
(ie crypto) de romans français ne parlant (ie maths) pas le français :-/
Certes. Mais tu négliges un GROS détail : les contributeurs du forums
ont derrière eux les centaines d'années de sciences mathématiques dont
ils se servent pour argumenter. Jusqu'à mes démonstrations et
applications qui ont démontré la faiblesse du procédé. Or, si je
m'avère compétent (à ton sens), les autres le sont au moins autant.
Raymond, pourquoi ai-je l'impression que tu implémentes une fonction de
hachage en ce qui concerne nos remarques ?
??? une fonction de hachage!#!!?##? Je ne suis pas sûr de comprendre.
C'est là où je voulais en arriver :
tu n'as pas les connaissances de
base pour construire ce genre d'algorithme dont les termes élémentaires
t'échappent.
Supposons que nous (on dit tous la même chose, donc : nous)
ayons raison. Nous possédons la science nécessaire pour se l'expliquer
entre nous et tout autre personne culturée. Mais tu ne peux pas
comprendre et, c'est le plus génant, accorder de valeur à nos écrits
parce que tu ne les comprends pas. C'est dommage.
...Ces fils sont à la suite justement de l'annonce d'AllCrypter
dans ce groupe de discussion,
Ca s'appelle du SPAM, en violation avec ma petite pensée à moi
que j'ai
sur l'usage des forums, et, en violation avec les chartes régissant la
hiérarchie fr.*.
Tu as d'ailleurs répété l'offense sur au moins un autre forum.
Au lieu de dire : "j'ai un algo qui tue, qui veut me le casser ?", tu as
posté un message à caractère commercial crade.
et mon but est de
développer ce 'Simple algo' en sorte que je le mette ou m'en inspire
pour la version 3 d'AllCrypter. Je tiens à ce que les gens utilisant
AllCrypter ait un logiciel sur lequel ils peuvent compter. C'est
pourquoi je veille à son amélioration POUR une version 3 interdisant
les attaques à clair ou chiffré connue ou d'autres sortes d'attaques.
Moi, j'y crois, et c'est à quoi je mets mon énergie ici.
Tout ce que tu vas arriver à faire c'est épuiser les compétences (dans
mon cas) et les énergies (de tous les contributeurs). Tout cela est fait
gratos, ne l'oublie pas.
L'énergie totale est limitée et tends à
s'épuiser.Je vous assure que j'ai pris en considération plusieurs de vos
remarques, même si je n'en fait pas toujours suite. De plus,
j'apprécie grandement vos contributions dans ce fil (étape 1 et 2, et
celle-ci). Dès le début j'ai apprécié la façon dont vous avez fait
vos interventions, même si la profondeur de vos calculs me laissait
quelque fois un peu derrière :-) Vous êtes même celui qui a le plus
souvent contribué et il est évident que vous n'êtes pas un débutant
en la matière.
Tu vas rire : je suis _débutant_ en la matière.
Ce n'est pas que je sois
modeste, mais juste réaliste. La crypto est pour moi un amusement, pas
mon métier principal. Imagine les autres...
C'est comme si un allemand (parlant très bien l'allemand) te disait
que tu es très fort parce que tu parles français :-o
Salut !l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Mais pas nécessairement le bon clair.
J'ose espérer que l'algo est réversible.
Bonjour,
Si j'utilise {clé1;clair1} pour générer chiffré1, on pourra donc, à partir
de {chiffré1;clé1} retrouver clair1.
Ce qui se passe ici c'est qu'il y a beaucoup de clés équivalentes à clé1.
J'ai clé2, clé3,... cléi qui sont équivalentes à clé1 au sens où toutes
ces clés associées à clair1 vont former chiffré1.
Donc chacune de ces clés permet de reformer clair1 à partir de chiffré1.
Ceci, évidemment, indépendamment d'une éventuelle surcouche à votre algo.
D'ailleurs, si vous vouliez bien présenter une spécification complète de
votre algo... c'est difficile de faire tomber une partie de votre algo, et
de vous entendre répondre "mais il n'y a pas que cela", sans savoir ce
qu'est le reste... Si vous ne donnez pas le reste, autant ne rien faire.
Je voulais aussi revenir là-dessus:Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Le nombre de caractères n'est pas extrêmement important ici. Vous aviez
une clé de 4 caractères, et je vous assure que mon programme n'a pas testé
les 4milliards et quelques clés possibles pour trouver l'ensemble des 640
qui fonctionnaient.
il n'en a en fait testé que 0.007%.
Ca peut encore paraitre beaucoup, mais le pourcentage à tester décroit
rapidement avec la taille de la clé...
Disons qu'après quelques centaines de calculs, environ 95% des clés
possibles sont déjà définitivement éliminées.
Et pour casser votre algo, rien ne sert d'avoir l'ensemble des clés
possibles. Une seule suffit.
Cordialement,
Salut !
l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Mais pas nécessairement le bon clair.
J'ose espérer que l'algo est réversible.
Bonjour,
Si j'utilise {clé1;clair1} pour générer chiffré1, on pourra donc, à partir
de {chiffré1;clé1} retrouver clair1.
Ce qui se passe ici c'est qu'il y a beaucoup de clés équivalentes à clé1.
J'ai clé2, clé3,... cléi qui sont équivalentes à clé1 au sens où toutes
ces clés associées à clair1 vont former chiffré1.
Donc chacune de ces clés permet de reformer clair1 à partir de chiffré1.
Ceci, évidemment, indépendamment d'une éventuelle surcouche à votre algo.
D'ailleurs, si vous vouliez bien présenter une spécification complète de
votre algo... c'est difficile de faire tomber une partie de votre algo, et
de vous entendre répondre "mais il n'y a pas que cela", sans savoir ce
qu'est le reste... Si vous ne donnez pas le reste, autant ne rien faire.
Je voulais aussi revenir là-dessus:
Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Le nombre de caractères n'est pas extrêmement important ici. Vous aviez
une clé de 4 caractères, et je vous assure que mon programme n'a pas testé
les 4milliards et quelques clés possibles pour trouver l'ensemble des 640
qui fonctionnaient.
il n'en a en fait testé que 0.007%.
Ca peut encore paraitre beaucoup, mais le pourcentage à tester décroit
rapidement avec la taille de la clé...
Disons qu'après quelques centaines de calculs, environ 95% des clés
possibles sont déjà définitivement éliminées.
Et pour casser votre algo, rien ne sert d'avoir l'ensemble des clés
possibles. Une seule suffit.
Cordialement,
Salut !l'exemple 3, n'importe quelle clé aurait convenu. A chaque clé
proposée, il aurait toujours été possible de trouver un clair.
Mais pas nécessairement le bon clair.
J'ose espérer que l'algo est réversible.
Bonjour,
Si j'utilise {clé1;clair1} pour générer chiffré1, on pourra donc, à partir
de {chiffré1;clé1} retrouver clair1.
Ce qui se passe ici c'est qu'il y a beaucoup de clés équivalentes à clé1.
J'ai clé2, clé3,... cléi qui sont équivalentes à clé1 au sens où toutes
ces clés associées à clair1 vont former chiffré1.
Donc chacune de ces clés permet de reformer clair1 à partir de chiffré1.
Ceci, évidemment, indépendamment d'une éventuelle surcouche à votre algo.
D'ailleurs, si vous vouliez bien présenter une spécification complète de
votre algo... c'est difficile de faire tomber une partie de votre algo, et
de vous entendre répondre "mais il n'y a pas que cela", sans savoir ce
qu'est le reste... Si vous ne donnez pas le reste, autant ne rien faire.
Je voulais aussi revenir là-dessus:Imaginez maintenant les possibilités pour décrypter un chiffré dont
vous ne connaissez pas le clair ni la clef; et encore pire si votre
texte comporte plus que 3 caractères.
Le nombre de caractères n'est pas extrêmement important ici. Vous aviez
une clé de 4 caractères, et je vous assure que mon programme n'a pas testé
les 4milliards et quelques clés possibles pour trouver l'ensemble des 640
qui fonctionnaient.
il n'en a en fait testé que 0.007%.
Ca peut encore paraitre beaucoup, mais le pourcentage à tester décroit
rapidement avec la taille de la clé...
Disons qu'après quelques centaines de calculs, environ 95% des clés
possibles sont déjà définitivement éliminées.
Et pour casser votre algo, rien ne sert d'avoir l'ensemble des clés
possibles. Une seule suffit.
Cordialement,
