"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: csc16i$31i4$1@biggoron.nerim.net...
> Le Sat, 15 Jan 2005 13:42:43 -0500, Raymond H. a écrit :
>
>> Dans ce cas ce ne serait pas vraiment sur l'algo de cryptage du clair
>> qu'il faudrait se pencher mais sur l'algo de prolongement d'une clef,
>
> C'est une erreur. Je vais faire description imagée. Imagine que la clé
> en question fasse deux caractères a et b, tu la prolonges de un
> caractère au moyen de l'opération c=a+b.
> La clé est ainsi (a,b,c). Question : (a,b,c) peut-il avoir toutes les
> combinaisons possibles de a,b et c ? Il s'agit de l'une des conditions
> draconiennes imposées à l'OTP auquel ton algo est, au mieux, équivalent.
>
> La réponse est non : le nombre de combinaisons ne sera que de 256², le
> troisième élément étant dépendant des deux autres. Or, la clé doit
> remplir entièrement les possibilités de combinaisons, soit 256**3, pour
> être correcte.
>
Il est presque certain qu'avec c=a+b ça ne tiendra pas. On suppose que
la clef doit avoir un minimum de caractères: 32 bits par exemple.
k = 1-2-3-4 (clef de session initiale créée aléatoirement)
m = 5-6-7-8-9-0 (clair)
x = 0 (au départ)
k5 = (((k2 + k3) xor m1) + k4) Modulo 256
c(x+1) = (((k1 + m(x+1) xor k2) + k1) Modulo 256 [Je simplifie ici]
x = x + 1
Dans notre exemple, on conserverait toujours 4 caractères dans notre
clef de session puisqu'elle avait 4 caractères lors de son initialisation.
donc k = 1-2-3-4
donc m = 5-6-7-8-9-0
On conserve donc la clef de session finale 20-21-37-78 pour pouvoir
déchiffrer le cryptogramme 6-16-19-13-31-21
En résumé avec:
m = 5-6-7-8-9-0
k = 1-2-3-4
on produit:
k = 2-3-4-4
c = 6
k = 3-4-4-5
c = 6-16
k = 4-4-5-20
c = 6-16-19
k = 4-5-20-21
c = 6-16-19-13
k = 5-20-21-37
c = 6-16-19-13-31
k = 20-21-37-78
c = 6-16-19-13-31-21
La question est: 'Pouvons-nous trouver le clair à partir de l'algo et du
chiffré 6-16-19-13-31-21 ?
x = 0 (au départ)
k5 = (((k2 + k3) xor m1) + k4) Modulo 256
c(x+1) = (((k1 + m(x+1) xor k2) + k1) Modulo 256
x = x + 1
Ici, j'ai fait un peu vite la partie de l'algo pour le prolongement de
la clef de session; faudrait regarder la façon la plus sûre. Mais, on
pourrait faire les additions et les xor avec d'autres valeurs:
Par exemple, au lieu de faire
k5 = ((k2 + k3) xor m1) + k4
on pourrait faire (en ajoutant le modulo que je n'ai pas mis pour que ce
soit plus simple à l'oeil):
k5 =( ((k2 + m1) xor k3) + k4) Modulo 256
Bonne journée.
Raymond H.
=================
N.B.:
En transformant
c1=(((k1 + k2 + m1 + m2) xor k2) + k1) Mod 256
c2=(((k2 + k3 + m2 + m3) xor k3) + k2) Mod 256
c3=(((k3 + k4 + m3 + k4 ) xor k4) + k3) Mod 256 (k4 remplace aussi m4)
en
c1=(((k1 + m1) xor k2) + k1) Mod 256
c2=(((k2 + m2) xor k3) + k2) Mod 256
c3=(((k3 + m3) xor k4) + k3) Mod 256 (k4 remplace aussi m4)
J'aurais aimé un simple 'oui' ou 'non' à la question suivante (sinon ça me laisserait sous-entendre n'importe quoi): "À cette 4e étape, peut-on (ou avez-vous réussis à) trouver la clef à partir du clair, du chiffré et l'algo, mais sans faire de force brute ou essayer des clefs différentes (même dans le code C) jusqu'à trouver le clair qui correspond au chiffré."
Non.
Peu importe les tests réalisés dans un tel programme. En fait, la question est : pourquoi faut-il éviter la force brute ?
Autrement dit: "Pourquoi est-il nécessaire d'empêcher quiconque de réussir une attaque à force brute?"
Si c'est bien le sens à votre question, est-ce une attaque à force brute à partir de la phrase de passe (à supposé qu'il y en ait une pour crypter la clef de session finale) ou à partir de la clef générée?
La grande caractéristique de l'attaque par force brute en général est qu'il s'agit de la moins mauvaise méthode si on ne sait pas comment attaquer un cryptosystème. Elle a aussi comme caractéristique d'être systématiquement contrée par tout système de chiffrement digne de ce nom : les temps de cassage deviennent trop longs.
L'attaque que j'expose est une attaque externe : un chiffré, une clair et l'algo. Le principe est indépendant de l'implantation. Ton chiffrément étant symétrique, les clés pour chiffrer et déchiffrer sont liés. La valeur de l'une est déduite de l'autre.
Dans mon programme, il n'y a pas de tests de clé au sens où tu l'entends. En fait, il y en a qu'un : c'est pour tester une clé complète et voir s'il n'y a pas eu d'erreur dans le programme. Mais c'est d'ordre cosmétique, pour ma tranquilité personnelle. Tous les calculs ont étés faits avant et composent progressivement la clé.
Donc, c'est un genre d'attaque à force brute (indirectement parce vous faite une analyse par calcul pour trouver des valeurs qui doivent rencontrer les critères de votre code).
Non. Pas de loin, ni de près.
Votre logiciel essais plusieurs valeurs jusqu'à en trouver qui correspondent à une clef qui rencontre les critères de votre code (de vos calculs).
Non. La clé est composée au fur et à mesure. Le seul test de chiffrement avec une clé est fait lorsqu'une clé a été trouvée, afin d'écarter une erreur de conception de ma part mais c'est facultatif.
Dans ce cas, il teste les clefs seulement selon les valeurs qui pourraient correspondre au critères de votre code selon l'algo, le clair et le chiffré.
Le programme fait ce que je lui dit de faire, encore heureux ! Il a en entrée le clair et le chiffré, est paramétré pour le SA v4 et délivre en sortie les clés qu'il a découvertes.
Voici un exemple avec une clé de 100 octets. Comme tu peux le voir, le temps d'exécution de l'algorithme ne dépend pas vraiment de la longueur de la clé. ... Vous auriez donc pris les valeurs de ce clair et de ce chiffré pour
trouver la clef par votre code, et ainsi voir si cela correspondait bien à la clef que vous aviez.
Ben oui !? C'est quand même mieux pour vérifier, non ? C'est que c'est long de saisir tous ces chiffres. Mais bon, si doutes il y a, soumets un clair, son chiffré et sa clé pour que je puisse tester et un autre clair avec son chiffré mais sans sa clé que je devrai trouver pour avancer mes dires, ce qui serait de bonne guerre (perdue).
... Moins d'un dixième de seconde pour trouver toutes les clés, certainement beaucoup moins pour la première. Nombre total de clés possibles : 256^100 = 6.668*10^240. Nombre d'itérations pour trouver une clé : 8675.
Ok. Donc par le mot itérations cela suppose qu'il y aurait eu effectivement au moins un certain nombre de clef qui ont été essayés avec de trouver la bonne qui correspondait avec le clair et le chiffré: 8675 clef ici.
Non ! Tu dois le savoir, un programme sans itérations est plutôt difficile à concevoir. Cela ne correspond pas à des tests de clés. Regarde plutôt cela à l'analogue d'un programme d'échec dont la puissance est désignée par le nombre de coups cherchables à la minute.
Optimisation de l'algo par rapport à une attaque par force brute, sachant qu'une telle attaque parcours en moyenne la moitié des clés possibles : 8675/(256^100/2) = 1.301*10^(-237). C'est-à-dire : 0,0...01301, le "0...0" étant à remplacer par 236 zéros, après la virgule.
Qu'essayez-vous de dire ici? :-) Car plus haut vous avez dit qu'en rallongeant la clef de mon algo cela pourrait empêcher la réussite de (ou décourager l'attaque par) la force brute.
Simple : j'entendais démontrer que mon approche n'est *pas* une force brute, auquel cas le programme tournerait encore à l'heure qu'il est. Considére l'ensemble de tes clés comme la longueur de la terre au soleil. Le programme en question, au lieu d'en parcourir la moitié, parcours beaucoup beaucoup moins qu'un atome, quark, ou même, corde. 150e9*8675/(256**100/2)=3,903e-226.
En fait, même en prenant la taille de l'univers actuel ça pourcourt beaucoup moins que la longueur de Plank...
Mais, par un code créé en C cela diminuerait de beaucoup de temps d'essais de la force brute (par itérations en interne, dans le code C). Je ne sais pas de combien de temps mais sûrement de beaucoup par rapport au logiciel de chiffrage lui-même.
Effectivement, cela prends plus de temps de faire le cassage que de chiffrer, encore heureux :-o Ceci dit, le chiffrement est d'une durée non-mesurable tandis que le cassage d'une clé de 100 octets est de l'ordre de la centième de seconde.
C, C++, Java ou cobol, ça reste des mathématiques. Le programme automatise juste ce que bien d'autres lecteurs du forum devraient avoir démontré de tête. J'ai juste conceptualisé l'attaque, prototypé et implanté. Cette dernière étape étant traditionnellement lourde, elle n'est faite que si l'attaquant est motivé et le défenseur buté ;-)
... en sorte que même si je donnerais les 3 premiers caractères du clair et de la clef cela pourrait être inutile vue le grand nombre d'autres caractères de la clef et du clair qui son inconnus de l'attaquant, et non créé par l'algo mais créé aléatoirement au début (clef initiale).
Voici ce qui conditionne la taille de l'échantillon du clair du chiffré pour connaître la clé : la taille des échantillons doit être au moins égal à la longueur de la clé. La clé faisait trois octets, il ne m'a donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un clair et un chiffré d'une longeur de 100 octets, la clé faisant cette taille.
Avec un clef de 64 bits dans cette étape 4, à combien de temps évaluez-vous une attaque à clair connu comme vous l'auriez fait (itération pour vérifier un certain nombre de clefs à partir du clair, du chiffré et de l'algo)?
0 s. Non mesurable, en fait.
100 octets font tout de même 800 bits. Et je peux monter beaucoup plus haut sans problème. C'est juste que ça fait lourd pour usenet, toutes ces clés ;-)
pour passer de 64 à 800 bits, il faut en ajouter 736. Il y a un facteur occupant 221 zéros entre les deux... 2**736=3.615*10^221
Aboule le clair et le chiffré. Tu auras (très très vite) une réponse sûre à ta question.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
J'aurais aimé un simple 'oui' ou 'non' à la question suivante (sinon ça
me laisserait sous-entendre n'importe quoi):
"À cette 4e étape, peut-on (ou avez-vous réussis à) trouver la clef à partir
du clair, du chiffré et l'algo, mais sans faire de force brute ou essayer
des clefs différentes (même dans le code C) jusqu'à trouver le clair qui
correspond au chiffré."
Non.
Peu importe les tests réalisés dans un tel programme. En fait,
la question est : pourquoi faut-il éviter la force brute ?
Autrement dit: "Pourquoi est-il nécessaire d'empêcher quiconque de
réussir une attaque à force brute?"
Si c'est bien le sens à votre question, est-ce une attaque à force brute à
partir de la phrase de passe (à supposé qu'il y en ait une pour crypter la
clef de session finale) ou à partir de la clef générée?
La grande caractéristique de l'attaque par force brute en général est
qu'il s'agit de la moins mauvaise méthode si on ne sait pas comment
attaquer un cryptosystème. Elle a aussi comme caractéristique d'être
systématiquement contrée par tout système de chiffrement digne de ce
nom : les temps de cassage deviennent trop longs.
L'attaque que j'expose est une attaque externe : un chiffré, une clair et
l'algo. Le principe est indépendant de l'implantation. Ton chiffrément
étant symétrique, les clés pour chiffrer et déchiffrer sont liés. La
valeur de l'une est déduite de l'autre.
Dans mon programme, il n'y a pas de tests de clé au sens où tu
l'entends. En fait, il y en a qu'un : c'est pour tester une clé complète
et voir s'il n'y a pas eu d'erreur dans le programme. Mais c'est d'ordre
cosmétique, pour ma tranquilité personnelle. Tous les calculs ont étés
faits avant et composent progressivement la clé.
Donc, c'est un genre d'attaque à force brute (indirectement parce vous
faite une analyse par calcul pour trouver des valeurs qui doivent rencontrer
les critères de votre code).
Non. Pas de loin, ni de près.
Votre logiciel essais plusieurs valeurs
jusqu'à en trouver qui correspondent à une clef qui rencontre les critères
de votre code (de vos calculs).
Non. La clé est composée au fur et à mesure. Le seul test de
chiffrement avec une clé est fait lorsqu'une clé a été trouvée, afin
d'écarter une erreur de conception de ma part mais c'est facultatif.
Dans ce cas, il teste les clefs seulement
selon les valeurs qui pourraient correspondre au critères de votre code
selon l'algo, le clair et le chiffré.
Le programme fait ce que je lui dit de faire, encore heureux ! Il a en
entrée le clair et le chiffré, est paramétré pour le SA v4 et délivre
en sortie les clés qu'il a découvertes.
Voici un exemple avec une clé de 100 octets. Comme tu peux le voir, le
temps d'exécution de l'algorithme ne dépend pas vraiment de la longueur
de la clé.
...
Vous auriez donc pris les valeurs de ce clair et de ce chiffré pour
trouver la clef par votre code, et ainsi voir si cela correspondait bien à
la clef que vous aviez.
Ben oui !? C'est quand même mieux pour vérifier, non ? C'est que c'est
long de saisir tous ces chiffres. Mais bon, si doutes il y a, soumets un
clair, son chiffré et sa clé pour que je puisse tester et un autre clair
avec son chiffré mais sans sa clé que je devrai trouver pour avancer
mes dires, ce qui serait de bonne guerre (perdue).
...
Moins d'un dixième de seconde pour trouver toutes les clés,
certainement beaucoup moins pour la première. Nombre total de clés
possibles : 256^100 = 6.668*10^240. Nombre d'itérations pour trouver
une clé : 8675.
Ok. Donc par le mot itérations cela suppose qu'il y aurait eu
effectivement au moins un certain nombre de clef qui ont été essayés
avec de trouver la bonne qui correspondait avec le clair et le chiffré:
8675 clef ici.
Non ! Tu dois le savoir, un programme sans itérations est plutôt
difficile à concevoir. Cela ne correspond pas à des tests de clés.
Regarde plutôt cela à l'analogue d'un programme d'échec dont la
puissance est désignée par le nombre de coups cherchables à la minute.
Optimisation de l'algo par rapport à une attaque par force brute,
sachant qu'une telle attaque parcours en moyenne la moitié des clés
possibles : 8675/(256^100/2) = 1.301*10^(-237). C'est-à-dire :
0,0...01301, le "0...0" étant à remplacer par 236 zéros, après la
virgule.
Qu'essayez-vous de dire ici? :-) Car plus haut vous avez dit qu'en
rallongeant la clef de mon algo cela pourrait empêcher la réussite de
(ou décourager l'attaque par) la force brute.
Simple : j'entendais démontrer que mon approche n'est *pas* une force
brute, auquel cas le programme tournerait encore à l'heure qu'il est.
Considére l'ensemble de tes clés comme la longueur de la terre au
soleil. Le programme en question, au lieu d'en parcourir la moitié,
parcours beaucoup beaucoup moins qu'un atome, quark, ou même, corde.
150e9*8675/(256**100/2)=3,903e-226.
En fait, même en prenant la taille de l'univers actuel ça pourcourt
beaucoup moins que la longueur de Plank...
Mais, par un code créé en C cela diminuerait de beaucoup de temps
d'essais de la force brute (par itérations en interne, dans le code C).
Je ne sais pas de combien de temps mais sûrement de beaucoup par
rapport au logiciel de chiffrage lui-même.
Effectivement, cela prends plus de temps de faire le cassage que de
chiffrer, encore heureux :-o Ceci dit, le chiffrement est d'une durée
non-mesurable tandis que le cassage d'une clé de 100 octets est de
l'ordre de la centième de seconde.
C, C++, Java ou cobol, ça reste des mathématiques. Le programme
automatise juste ce que bien d'autres lecteurs du forum devraient avoir
démontré de tête. J'ai juste conceptualisé l'attaque, prototypé et
implanté. Cette dernière étape étant traditionnellement lourde, elle
n'est faite que si l'attaquant est motivé et le défenseur buté ;-)
...
en sorte que même si je donnerais les 3 premiers
caractères du clair et de la clef cela pourrait être inutile vue le
grand nombre d'autres caractères de la clef et du clair qui son
inconnus de l'attaquant, et non créé par l'algo mais créé
aléatoirement au début (clef initiale).
Voici ce qui conditionne la taille de l'échantillon du clair du chiffré
pour connaître la clé : la taille des échantillons doit être au moins
égal à la longueur de la clé. La clé faisait trois octets, il ne m'a
donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un
clair et un chiffré d'une longeur de 100 octets, la clé faisant cette
taille.
Avec un clef de 64 bits dans
cette étape 4, à combien de temps évaluez-vous une attaque à clair
connu comme vous l'auriez fait (itération pour vérifier un certain
nombre de clefs à partir du clair, du chiffré et de l'algo)?
0 s. Non mesurable, en fait.
100 octets font tout de même 800 bits. Et je peux monter beaucoup plus
haut sans problème. C'est juste que ça fait lourd pour usenet, toutes
ces clés ;-)
pour passer de 64 à 800 bits, il faut en ajouter 736. Il y a un facteur
occupant 221 zéros entre les deux...
2**736=3.615*10^221
Aboule le clair et le chiffré. Tu auras (très très vite) une réponse
sûre à ta question.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
J'aurais aimé un simple 'oui' ou 'non' à la question suivante (sinon ça me laisserait sous-entendre n'importe quoi): "À cette 4e étape, peut-on (ou avez-vous réussis à) trouver la clef à partir du clair, du chiffré et l'algo, mais sans faire de force brute ou essayer des clefs différentes (même dans le code C) jusqu'à trouver le clair qui correspond au chiffré."
Non.
Peu importe les tests réalisés dans un tel programme. En fait, la question est : pourquoi faut-il éviter la force brute ?
Autrement dit: "Pourquoi est-il nécessaire d'empêcher quiconque de réussir une attaque à force brute?"
Si c'est bien le sens à votre question, est-ce une attaque à force brute à partir de la phrase de passe (à supposé qu'il y en ait une pour crypter la clef de session finale) ou à partir de la clef générée?
La grande caractéristique de l'attaque par force brute en général est qu'il s'agit de la moins mauvaise méthode si on ne sait pas comment attaquer un cryptosystème. Elle a aussi comme caractéristique d'être systématiquement contrée par tout système de chiffrement digne de ce nom : les temps de cassage deviennent trop longs.
L'attaque que j'expose est une attaque externe : un chiffré, une clair et l'algo. Le principe est indépendant de l'implantation. Ton chiffrément étant symétrique, les clés pour chiffrer et déchiffrer sont liés. La valeur de l'une est déduite de l'autre.
Dans mon programme, il n'y a pas de tests de clé au sens où tu l'entends. En fait, il y en a qu'un : c'est pour tester une clé complète et voir s'il n'y a pas eu d'erreur dans le programme. Mais c'est d'ordre cosmétique, pour ma tranquilité personnelle. Tous les calculs ont étés faits avant et composent progressivement la clé.
Donc, c'est un genre d'attaque à force brute (indirectement parce vous faite une analyse par calcul pour trouver des valeurs qui doivent rencontrer les critères de votre code).
Non. Pas de loin, ni de près.
Votre logiciel essais plusieurs valeurs jusqu'à en trouver qui correspondent à une clef qui rencontre les critères de votre code (de vos calculs).
Non. La clé est composée au fur et à mesure. Le seul test de chiffrement avec une clé est fait lorsqu'une clé a été trouvée, afin d'écarter une erreur de conception de ma part mais c'est facultatif.
Dans ce cas, il teste les clefs seulement selon les valeurs qui pourraient correspondre au critères de votre code selon l'algo, le clair et le chiffré.
Le programme fait ce que je lui dit de faire, encore heureux ! Il a en entrée le clair et le chiffré, est paramétré pour le SA v4 et délivre en sortie les clés qu'il a découvertes.
Voici un exemple avec une clé de 100 octets. Comme tu peux le voir, le temps d'exécution de l'algorithme ne dépend pas vraiment de la longueur de la clé. ... Vous auriez donc pris les valeurs de ce clair et de ce chiffré pour
trouver la clef par votre code, et ainsi voir si cela correspondait bien à la clef que vous aviez.
Ben oui !? C'est quand même mieux pour vérifier, non ? C'est que c'est long de saisir tous ces chiffres. Mais bon, si doutes il y a, soumets un clair, son chiffré et sa clé pour que je puisse tester et un autre clair avec son chiffré mais sans sa clé que je devrai trouver pour avancer mes dires, ce qui serait de bonne guerre (perdue).
... Moins d'un dixième de seconde pour trouver toutes les clés, certainement beaucoup moins pour la première. Nombre total de clés possibles : 256^100 = 6.668*10^240. Nombre d'itérations pour trouver une clé : 8675.
Ok. Donc par le mot itérations cela suppose qu'il y aurait eu effectivement au moins un certain nombre de clef qui ont été essayés avec de trouver la bonne qui correspondait avec le clair et le chiffré: 8675 clef ici.
Non ! Tu dois le savoir, un programme sans itérations est plutôt difficile à concevoir. Cela ne correspond pas à des tests de clés. Regarde plutôt cela à l'analogue d'un programme d'échec dont la puissance est désignée par le nombre de coups cherchables à la minute.
Optimisation de l'algo par rapport à une attaque par force brute, sachant qu'une telle attaque parcours en moyenne la moitié des clés possibles : 8675/(256^100/2) = 1.301*10^(-237). C'est-à-dire : 0,0...01301, le "0...0" étant à remplacer par 236 zéros, après la virgule.
Qu'essayez-vous de dire ici? :-) Car plus haut vous avez dit qu'en rallongeant la clef de mon algo cela pourrait empêcher la réussite de (ou décourager l'attaque par) la force brute.
Simple : j'entendais démontrer que mon approche n'est *pas* une force brute, auquel cas le programme tournerait encore à l'heure qu'il est. Considére l'ensemble de tes clés comme la longueur de la terre au soleil. Le programme en question, au lieu d'en parcourir la moitié, parcours beaucoup beaucoup moins qu'un atome, quark, ou même, corde. 150e9*8675/(256**100/2)=3,903e-226.
En fait, même en prenant la taille de l'univers actuel ça pourcourt beaucoup moins que la longueur de Plank...
Mais, par un code créé en C cela diminuerait de beaucoup de temps d'essais de la force brute (par itérations en interne, dans le code C). Je ne sais pas de combien de temps mais sûrement de beaucoup par rapport au logiciel de chiffrage lui-même.
Effectivement, cela prends plus de temps de faire le cassage que de chiffrer, encore heureux :-o Ceci dit, le chiffrement est d'une durée non-mesurable tandis que le cassage d'une clé de 100 octets est de l'ordre de la centième de seconde.
C, C++, Java ou cobol, ça reste des mathématiques. Le programme automatise juste ce que bien d'autres lecteurs du forum devraient avoir démontré de tête. J'ai juste conceptualisé l'attaque, prototypé et implanté. Cette dernière étape étant traditionnellement lourde, elle n'est faite que si l'attaquant est motivé et le défenseur buté ;-)
... en sorte que même si je donnerais les 3 premiers caractères du clair et de la clef cela pourrait être inutile vue le grand nombre d'autres caractères de la clef et du clair qui son inconnus de l'attaquant, et non créé par l'algo mais créé aléatoirement au début (clef initiale).
Voici ce qui conditionne la taille de l'échantillon du clair du chiffré pour connaître la clé : la taille des échantillons doit être au moins égal à la longueur de la clé. La clé faisait trois octets, il ne m'a donc fallu que trois octets de chaque. Dans mon exemple, il me fallait un clair et un chiffré d'une longeur de 100 octets, la clé faisant cette taille.
Avec un clef de 64 bits dans cette étape 4, à combien de temps évaluez-vous une attaque à clair connu comme vous l'auriez fait (itération pour vérifier un certain nombre de clefs à partir du clair, du chiffré et de l'algo)?
0 s. Non mesurable, en fait.
100 octets font tout de même 800 bits. Et je peux monter beaucoup plus haut sans problème. C'est juste que ça fait lourd pour usenet, toutes ces clés ;-)
pour passer de 64 à 800 bits, il faut en ajouter 736. Il y a un facteur occupant 221 zéros entre les deux... 2**736=3.615*10^221
Aboule le clair et le chiffré. Tu auras (très très vite) une réponse sûre à ta question.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Raymond H.
"Christophe HENRY" a écrit dans le message de news: csqkga$15u$
J'aurais aimé un simple 'oui' ou 'non' à la question suivante (sinon ça me laisserait sous-entendre n'importe quoi): "À cette 4e étape, peut-on (ou avez-vous réussis à) trouver la clef à partir du clair, du chiffré et l'algo, mais sans faire de force brute ou essayer des clefs différentes (même dans le code C) jusqu'à trouver le clair qui correspond au chiffré."
Non.
Merci :-)
Vous auriez donc pris les valeurs de ce clair et de ce chiffré pour trouver la clef par votre code, et ainsi voir si cela correspondait bien à la clef que vous aviez.
Ben oui !? C'est quand même mieux pour vérifier, non ? C'est que c'est long de saisir tous ces chiffres. Mais bon, si doutes il y a, soumets un clair, son chiffré et sa clé pour que je puisse tester et un autre clair avec son chiffré mais sans sa clé que je devrai trouver pour avancer mes dires, ce qui serait de bonne guerre (perdue).
Pas nécessaire, je vous crois sur parole :-)
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo' (y compris la 3e étape) ?
Dites! Le fait qu'il vous est possible de trouver la clef à partir du clair et du chiffré c'est bien parce que l'algo est fixe, c'est à dire qu'il est régulier du début du chiffrement jusqu'à la fin du chiffrement? Si c'est bien ça, alors peut importe l'algo vous arriverez toujours à trouver la clef de la façon dont vous faites (à partir du clair et du chiffré). N'est-ce pas? Faudrait que les calculs de l'algo soient imprévisibles dans son processus de chiffrement.
Bonne journée r.h.
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: csqkga$15u$1@biggoron.nerim.net...
J'aurais aimé un simple 'oui' ou 'non' à la question suivante (sinon
ça
me laisserait sous-entendre n'importe quoi):
"À cette 4e étape, peut-on (ou avez-vous réussis à) trouver la clef à
partir
du clair, du chiffré et l'algo, mais sans faire de force brute ou essayer
des clefs différentes (même dans le code C) jusqu'à trouver le clair qui
correspond au chiffré."
Non.
Merci :-)
Vous auriez donc pris les valeurs de ce clair et de ce chiffré pour
trouver la clef par votre code, et ainsi voir si cela correspondait bien
à
la clef que vous aviez.
Ben oui !? C'est quand même mieux pour vérifier, non ? C'est que c'est
long de saisir tous ces chiffres. Mais bon, si doutes il y a, soumets un
clair, son chiffré et sa clé pour que je puisse tester et un autre clair
avec son chiffré mais sans sa clé que je devrai trouver pour avancer
mes dires, ce qui serait de bonne guerre (perdue).
Pas nécessaire, je vous crois sur parole :-)
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir
du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo'
(y compris la 3e étape) ?
Dites! Le fait qu'il vous est possible de trouver la clef à partir du
clair et du chiffré c'est bien parce que l'algo est fixe, c'est à dire qu'il
est régulier du début du chiffrement jusqu'à la fin du chiffrement? Si
c'est bien ça, alors peut importe l'algo vous arriverez toujours à trouver
la clef de la façon dont vous faites (à partir du clair et du chiffré).
N'est-ce pas? Faudrait que les calculs de l'algo soient imprévisibles dans
son processus de chiffrement.
"Christophe HENRY" a écrit dans le message de news: csqkga$15u$
J'aurais aimé un simple 'oui' ou 'non' à la question suivante (sinon ça me laisserait sous-entendre n'importe quoi): "À cette 4e étape, peut-on (ou avez-vous réussis à) trouver la clef à partir du clair, du chiffré et l'algo, mais sans faire de force brute ou essayer des clefs différentes (même dans le code C) jusqu'à trouver le clair qui correspond au chiffré."
Non.
Merci :-)
Vous auriez donc pris les valeurs de ce clair et de ce chiffré pour trouver la clef par votre code, et ainsi voir si cela correspondait bien à la clef que vous aviez.
Ben oui !? C'est quand même mieux pour vérifier, non ? C'est que c'est long de saisir tous ces chiffres. Mais bon, si doutes il y a, soumets un clair, son chiffré et sa clé pour que je puisse tester et un autre clair avec son chiffré mais sans sa clé que je devrai trouver pour avancer mes dires, ce qui serait de bonne guerre (perdue).
Pas nécessaire, je vous crois sur parole :-)
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo' (y compris la 3e étape) ?
Dites! Le fait qu'il vous est possible de trouver la clef à partir du clair et du chiffré c'est bien parce que l'algo est fixe, c'est à dire qu'il est régulier du début du chiffrement jusqu'à la fin du chiffrement? Si c'est bien ça, alors peut importe l'algo vous arriverez toujours à trouver la clef de la façon dont vous faites (à partir du clair et du chiffré). N'est-ce pas? Faudrait que les calculs de l'algo soient imprévisibles dans son processus de chiffrement.
Bonne journée r.h.
Christophe HENRY
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo' (y compris la 3e étape) ?
Tout-à-fait. Pour les premiers schémas, j'ai procédé d'abord avec du calcul matriciel, par facilité. Depuis l'apparition du xor dans tes formules, je dois recourir à du C, ce qui est plus lent à concevoir mais bien plus rapide à l'exécution comme me l'a fait voir Jack.
Depuis le départ tes procédés sont cassables. Je suis un débutant dans le domaine, je le reécris encore. Les spécialistes ont vu autant que moi que tes principes de base ne te permettent pas d'accéder à un niveau pourtant indispensable pour créer un algorithme de chiffrement modérément fiable. Des intervenants te l'ont dit en avance, mais j'ai préféré te le montrer directement de manière irréfutable.
Nous n'avons pas inventé la manip', néamoins ;-p CDP : http://perso.wanadoo.fr/antmonni/cdpsid/
... Faudrait que les calculs de l'algo soient imprévisibles dans son processus de chiffrement.
Et pourtant il faut tout de même déchiffrer. L'algorithme doit être connu de tous. Seules les clés peuvent être secrètes. L'attaque par force brute ne doit pas être exploitable, le temps pour casser un message par cette voie doit être trop grand par rapport aux enjeux. L'algo ne doit pas présenter des faiblesses telles que celles indiquées pour le SA qui permettent d'avoir un calcul (quasiment) indépendant de la taille de la clé.
L'algorithme utilisé dans le 'simple algo' est faible, inutilisable. Il faut *changer* *totalement* de procédé. Par extension, j'imagine que AllCrypter présenté sur [logicipc.com] est cassable, cracable par force brute (bien avant 2006), à défaut, par une découverte du mot de passe, phrase de passe, ou clé de cryptage, ou clé de chiffrement comme je l'ai montré pour tes prototypes. Naturellement, ton mode de développement est propriétaire, ce qui interdit toute confiance préalable envers le programme puisque ses sources ne seront pas publique donc disponibles. Passe encore que pour l'interface graphique (pour l'encryption et le décryptage) les heures passées à la coder soient proprio, mais l'algorithme doit impérativement être tenu public. La sécurité par l'obscurité procure une sécurité très limitée.
Ce que j'appele (mais ça ne reste naturelmmenet que mon avis) le "spam" initial as dû te permettre de t'en rendre compte ; et je trouve que c'est plutôt sain comme démarche :-)
Une idée, en passant : conserve ton interface graphique mais sous-traite la partie chiffrement à un Logiciel Libre tel que gnupg. Mozilla Thunderbird le fait, avec l'extension Enigmail, par exemple.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir
du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo'
(y compris la 3e étape) ?
Tout-à-fait. Pour les premiers schémas, j'ai procédé d'abord avec du
calcul matriciel, par facilité. Depuis l'apparition du xor dans tes
formules, je dois recourir à du C, ce qui est plus lent à concevoir mais
bien plus rapide à l'exécution comme me l'a fait voir Jack.
Depuis le départ tes procédés sont cassables. Je suis un débutant dans
le domaine, je le reécris encore. Les spécialistes ont vu autant
que moi que tes principes de base ne te permettent pas d'accéder à un
niveau pourtant indispensable pour créer un algorithme de chiffrement
modérément fiable. Des intervenants te l'ont dit en avance, mais j'ai
préféré te le montrer directement de manière irréfutable.
Nous n'avons pas inventé la manip', néamoins ;-p
CDP : http://perso.wanadoo.fr/antmonni/cdpsid/
...
Faudrait que les calculs de l'algo soient imprévisibles dans son
processus de chiffrement.
Et pourtant il faut tout de même déchiffrer. L'algorithme doit être
connu de tous. Seules les clés peuvent être secrètes. L'attaque par
force brute ne doit pas être exploitable, le temps pour casser un
message par cette voie doit être trop grand par rapport aux enjeux.
L'algo ne doit pas présenter des faiblesses telles que celles indiquées
pour le SA qui permettent d'avoir un calcul (quasiment) indépendant de la
taille de la clé.
L'algorithme utilisé dans le 'simple algo' est faible, inutilisable. Il
faut *changer* *totalement* de procédé. Par extension, j'imagine que
AllCrypter présenté sur [logicipc.com] est cassable, cracable par
force brute (bien avant 2006), à défaut, par une découverte du mot de
passe, phrase de passe, ou clé de cryptage, ou clé de chiffrement comme
je l'ai montré pour tes prototypes. Naturellement, ton mode de
développement est propriétaire, ce qui interdit toute confiance
préalable envers le programme puisque ses sources ne seront pas
publique donc disponibles. Passe encore que pour l'interface graphique
(pour l'encryption et le décryptage) les heures passées à la coder
soient proprio, mais l'algorithme doit impérativement être tenu public.
La sécurité par l'obscurité procure une sécurité très limitée.
Ce que j'appele (mais ça ne reste naturelmmenet que mon avis) le "spam"
initial as dû te permettre de t'en rendre compte ; et je trouve que c'est
plutôt sain comme démarche :-)
Une idée, en passant : conserve ton interface graphique mais sous-traite
la partie chiffrement à un Logiciel Libre tel que gnupg. Mozilla
Thunderbird le fait, avec l'extension Enigmail, par exemple.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo' (y compris la 3e étape) ?
Tout-à-fait. Pour les premiers schémas, j'ai procédé d'abord avec du calcul matriciel, par facilité. Depuis l'apparition du xor dans tes formules, je dois recourir à du C, ce qui est plus lent à concevoir mais bien plus rapide à l'exécution comme me l'a fait voir Jack.
Depuis le départ tes procédés sont cassables. Je suis un débutant dans le domaine, je le reécris encore. Les spécialistes ont vu autant que moi que tes principes de base ne te permettent pas d'accéder à un niveau pourtant indispensable pour créer un algorithme de chiffrement modérément fiable. Des intervenants te l'ont dit en avance, mais j'ai préféré te le montrer directement de manière irréfutable.
Nous n'avons pas inventé la manip', néamoins ;-p CDP : http://perso.wanadoo.fr/antmonni/cdpsid/
... Faudrait que les calculs de l'algo soient imprévisibles dans son processus de chiffrement.
Et pourtant il faut tout de même déchiffrer. L'algorithme doit être connu de tous. Seules les clés peuvent être secrètes. L'attaque par force brute ne doit pas être exploitable, le temps pour casser un message par cette voie doit être trop grand par rapport aux enjeux. L'algo ne doit pas présenter des faiblesses telles que celles indiquées pour le SA qui permettent d'avoir un calcul (quasiment) indépendant de la taille de la clé.
L'algorithme utilisé dans le 'simple algo' est faible, inutilisable. Il faut *changer* *totalement* de procédé. Par extension, j'imagine que AllCrypter présenté sur [logicipc.com] est cassable, cracable par force brute (bien avant 2006), à défaut, par une découverte du mot de passe, phrase de passe, ou clé de cryptage, ou clé de chiffrement comme je l'ai montré pour tes prototypes. Naturellement, ton mode de développement est propriétaire, ce qui interdit toute confiance préalable envers le programme puisque ses sources ne seront pas publique donc disponibles. Passe encore que pour l'interface graphique (pour l'encryption et le décryptage) les heures passées à la coder soient proprio, mais l'algorithme doit impérativement être tenu public. La sécurité par l'obscurité procure une sécurité très limitée.
Ce que j'appele (mais ça ne reste naturelmmenet que mon avis) le "spam" initial as dû te permettre de t'en rendre compte ; et je trouve que c'est plutôt sain comme démarche :-)
Une idée, en passant : conserve ton interface graphique mais sous-traite la partie chiffrement à un Logiciel Libre tel que gnupg. Mozilla Thunderbird le fait, avec l'extension Enigmail, par exemple.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Noshi
On Thu, 20 Jan 2005 12:48:27 +0100, AMcD® wrote:
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non seulement ses maths foirent, mais sa programmation aussi. Et quand on utilise Visual Basic de surcroit... Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Autant je loue ton opiniatreté, autant je ne comprends pas son obstination. Remarque, ça met de l'animation.
Je préférais CDP.
-- Noshi
On Thu, 20 Jan 2005 12:48:27 +0100, AMcD® wrote:
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais
il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non
seulement ses maths foirent, mais sa programmation aussi. Et quand on
utilise Visual Basic de surcroit... Bref, ce ne sont pas les points
d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Autant je loue ton opiniatreté, autant je ne comprends pas son obstination.
Remarque, ça met de l'animation.
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non seulement ses maths foirent, mais sa programmation aussi. Et quand on utilise Visual Basic de surcroit... Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Autant je loue ton opiniatreté, autant je ne comprends pas son obstination. Remarque, ça met de l'animation.
Je préférais CDP.
-- Noshi
AMcD®
Noshi wrote:
On Thu, 20 Jan 2005 12:48:27 +0100, AMcD® wrote:
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non seulement ses maths foirent, mais sa programmation aussi. Et quand on utilise Visual Basic de surcroit... Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Ce que je voulais dire c'est que même si, par extraordinaire, il trouvait un algo valable, comme ce sera codé en VB ça ouvrira des portes supplémentaires pour craquer le truc encore plus vite. Pas l'algo en lui-même, mais le soft. Enfin, tant qu'il faut pas désassembler :-).
Je préférais CDP.
D'ailleurs, j'ai pas trop suivi la fin de l'épopée. Cela s'est terminé comment au fait, tu le sais ? Suicide, brevet international, fuite sur la lune ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Noshi wrote:
On Thu, 20 Jan 2005 12:48:27 +0100, AMcD® wrote:
Quand il aura une nouvelle version, moi ou d'autres lui
recraqueront, mais il ne comprendra toujours pas. Et cela pourra
durer ad vitam etaernam. Non seulement ses maths foirent, mais sa
programmation aussi. Et quand on utilise Visual Basic de surcroit...
Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Ce que je voulais dire c'est que même si, par extraordinaire, il trouvait un
algo valable, comme ce sera codé en VB ça ouvrira des portes supplémentaires
pour craquer le truc encore plus vite. Pas l'algo en lui-même, mais le soft.
Enfin, tant qu'il faut pas désassembler :-).
Je préférais CDP.
D'ailleurs, j'ai pas trop suivi la fin de l'épopée. Cela s'est terminé
comment au fait, tu le sais ? Suicide, brevet international, fuite sur la
lune ?
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non seulement ses maths foirent, mais sa programmation aussi. Et quand on utilise Visual Basic de surcroit... Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Ce que je voulais dire c'est que même si, par extraordinaire, il trouvait un algo valable, comme ce sera codé en VB ça ouvrira des portes supplémentaires pour craquer le truc encore plus vite. Pas l'algo en lui-même, mais le soft. Enfin, tant qu'il faut pas désassembler :-).
Je préférais CDP.
D'ailleurs, j'ai pas trop suivi la fin de l'épopée. Cela s'est terminé comment au fait, tu le sais ? Suicide, brevet international, fuite sur la lune ?
-- AMcD®
http://arnold.mcdonald.free.fr/
Raymond H.
Bonjour,
"Christophe HENRY" a écrit dans le message de news: csrrhj$hoe$
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo' (y compris la 3e étape) ?
Tout-à-fait. Pour les premiers schémas, j'ai procédé d'abord avec du calcul matriciel, par facilité. Depuis l'apparition du xor dans tes formules, je dois recourir à du C, ce qui est plus lent à concevoir mais bien plus rapide à l'exécution comme me l'a fait voir Jack.
Depuis le départ tes procédés sont cassables.
'TES'? Mais non, pas tous. :-) Mon dernier procédé dont j'ai dit que j'adopterais, lequel j'ai expliqué vouloir gardé et améliorer personne ne l'a encore cassé puisque non cassable pour l'instant (selon que vous avez dit vous-même). Il est vrai que je n'ai pas terminé, et la suite est critique (la génération de la clef et le chiffrage de la clef de session par la phrase de passe). Autrement dit, je parle de trouver le clair à partir de l'algo et du chiffré seulement, et cela sans posséder de clef. Vous l'avez dit vous-même qu'il est impossible de trouver cela. Mais, tout n'est pas terminé puisqu'il y a la 'clef de session' finale à crypter par la phrase de passe.
J'essais de comprendre le pour et le contre de vos interventions. Car ce que vous faites concernant le clair, moi je l'analyse pour la clef et non seulement pour le clair. Mais, bien entendu je ne néglige pas le fait qu'e l'extension d'un nom de fichier peut suggérer l'entête. J'y réfléchi à cela aussi afin de rendre imprévisible le calcul de chiffrage (variant selon certaines valeurs de caractères).
Je suis présentement à faire des tests pour comprendre certaines différences de calculs et où les employer ou non. Exemple: un simple XOR offre plus de possibilité qu'un XOR avec une addition:
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
"((Valeur1 + Valeur1) xor Valeur2 ) = 164" donne 128 possibilités etc.
Je suis un débutant dans le domaine, je le reécris encore. Les spécialistes ont vu autant que moi que tes principes de base ne te permettent pas d'accéder à un niveau pourtant indispensable pour créer un algorithme de chiffrement modérément fiable. Des intervenants te l'ont dit en avance, mais j'ai préféré te le montrer directement de manière irréfutable.
Le 'TES' est de trop :-) pour la même raison plus haut. Je ne généralise pas.
... Faudrait que les calculs de l'algo soient imprévisibles dans son processus de chiffrement.
Et pourtant il faut tout de même déchiffrer.
Oui.
L'algorithme doit être connu de tous.
Oui.
Seules les clés peuvent être secrètes.
Et le clair dans mon cas: selon le principe de Vernam à 'masque jetable'.
L'attaque par force brute ne doit pas être exploitable, le temps pour casser un message par cette voie doit être trop grand par rapport aux enjeux.
Certainement.
L'algo ne doit pas présenter des faiblesses telles que celles indiquées pour le SA qui permettent d'avoir un calcul (quasiment) indépendant de la taille de la clé.
"Un calcul (quasiment) indépendant de la taille de la clé." Ceci n'est-il pas possible seulement en rapport avec un clair, un chiffré et un algo connu?
L'algorithme utilisé dans le 'simple algo' est faible, inutilisable. Il faut *changer* *totalement* de procédé.
Pas dans cette dernière étape avec juste un chiffré et un algo connu. Au dernier stade il peut être utilisable (mais il faut que je développe la partie transformant la clef de session finale en un code d'identification de la phrase de passe 'avec du xor': un nouvelle idée dont je viens d'avoir; car transmettre une clef de session finale à chaque fois cela n'est pas très commode) et n'est pas faible (selon décrit plus haut). Ici je n'oublie cependant pas le fait qu'il est possible que l'entête d'un fichier puisse être connu par l'extension de son nom. Je n'oublie pas non plus les répétitions dans un chiffré: par exemple avec un clair n'ayant que des caractères ascii zéro au début. C'est pourquoi je n'ai pas terminé de réfléchir à rendre imprévisible certains calculs de l'algo et non seulement la clef.
La sécurité par l'obscurité procure une sécurité très limitée.
D'accord.
Bonne journée r.h.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: csrrhj$hoe$1@biggoron.nerim.net...
Si je ne me trompe vous pouviez trouver la clef de cette façon (à
partir
du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple
algo'
(y compris la 3e étape) ?
Tout-à-fait. Pour les premiers schémas, j'ai procédé d'abord avec du
calcul matriciel, par facilité. Depuis l'apparition du xor dans tes
formules, je dois recourir à du C, ce qui est plus lent à concevoir mais
bien plus rapide à l'exécution comme me l'a fait voir Jack.
Depuis le départ tes procédés sont cassables.
'TES'? Mais non, pas tous. :-) Mon dernier procédé dont j'ai dit que
j'adopterais, lequel j'ai expliqué vouloir gardé et améliorer personne ne
l'a encore cassé puisque non cassable pour l'instant (selon que vous avez
dit vous-même). Il est vrai que je n'ai pas terminé, et la suite est
critique (la génération de la clef et le chiffrage de la clef de session par
la phrase de passe). Autrement dit, je parle de trouver le clair à partir
de l'algo et du chiffré seulement, et cela sans posséder de clef. Vous
l'avez dit vous-même qu'il est impossible de trouver cela. Mais, tout n'est
pas terminé puisqu'il y a la 'clef de session' finale à crypter par la
phrase de passe.
J'essais de comprendre le pour et le contre de vos interventions. Car
ce que vous faites concernant le clair, moi je l'analyse pour la clef et non
seulement pour le clair. Mais, bien entendu je ne néglige pas le fait qu'e
l'extension d'un nom de fichier peut suggérer l'entête. J'y réfléchi à cela
aussi afin de rendre imprévisible le calcul de chiffrage (variant selon
certaines valeurs de caractères).
Je suis présentement à faire des tests pour comprendre certaines
différences de calculs et où les employer ou non. Exemple: un simple XOR
offre plus de possibilité qu'un XOR avec une addition:
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
"((Valeur1 + Valeur1) xor Valeur2 ) = 164" donne 128 possibilités
etc.
Je suis un débutant dans
le domaine, je le reécris encore. Les spécialistes ont vu autant
que moi que tes principes de base ne te permettent pas d'accéder à un
niveau pourtant indispensable pour créer un algorithme de chiffrement
modérément fiable. Des intervenants te l'ont dit en avance, mais j'ai
préféré te le montrer directement de manière irréfutable.
Le 'TES' est de trop :-) pour la même raison plus haut. Je ne
généralise pas.
...
Faudrait que les calculs de l'algo soient imprévisibles dans son
processus de chiffrement.
Et pourtant il faut tout de même déchiffrer.
Oui.
L'algorithme doit être
connu de tous.
Oui.
Seules les clés peuvent être secrètes.
Et le clair dans mon cas: selon le principe de Vernam à 'masque
jetable'.
L'attaque par
force brute ne doit pas être exploitable, le temps pour casser un
message par cette voie doit être trop grand par rapport aux enjeux.
Certainement.
L'algo ne doit pas présenter des faiblesses telles que celles indiquées
pour le SA qui permettent d'avoir un calcul (quasiment) indépendant de la
taille de la clé.
"Un calcul (quasiment) indépendant de la taille de la clé." Ceci
n'est-il pas possible seulement en rapport avec un clair, un chiffré et un
algo connu?
L'algorithme utilisé dans le 'simple algo' est faible, inutilisable. Il
faut *changer* *totalement* de procédé.
Pas dans cette dernière étape avec juste un chiffré et un algo connu.
Au dernier stade il peut être utilisable (mais il faut que je développe la
partie transformant la clef de session finale en un code d'identification de
la phrase de passe 'avec du xor': un nouvelle idée dont je viens d'avoir;
car transmettre une clef de session finale à chaque fois cela n'est pas très
commode) et n'est pas faible (selon décrit plus haut). Ici je n'oublie
cependant pas le fait qu'il est possible que l'entête d'un fichier puisse
être connu par l'extension de son nom. Je n'oublie pas non plus les
répétitions dans un chiffré: par exemple avec un clair n'ayant que des
caractères ascii zéro au début. C'est pourquoi je n'ai pas terminé de
réfléchir à rendre imprévisible certains calculs de l'algo et non seulement
la clef.
La sécurité par l'obscurité procure une sécurité très limitée.
"Christophe HENRY" a écrit dans le message de news: csrrhj$hoe$
Si je ne me trompe vous pouviez trouver la clef de cette façon (à partir du clair, du chiffré et de l'algo) dans toutes les l'étapes du 'Simple algo' (y compris la 3e étape) ?
Tout-à-fait. Pour les premiers schémas, j'ai procédé d'abord avec du calcul matriciel, par facilité. Depuis l'apparition du xor dans tes formules, je dois recourir à du C, ce qui est plus lent à concevoir mais bien plus rapide à l'exécution comme me l'a fait voir Jack.
Depuis le départ tes procédés sont cassables.
'TES'? Mais non, pas tous. :-) Mon dernier procédé dont j'ai dit que j'adopterais, lequel j'ai expliqué vouloir gardé et améliorer personne ne l'a encore cassé puisque non cassable pour l'instant (selon que vous avez dit vous-même). Il est vrai que je n'ai pas terminé, et la suite est critique (la génération de la clef et le chiffrage de la clef de session par la phrase de passe). Autrement dit, je parle de trouver le clair à partir de l'algo et du chiffré seulement, et cela sans posséder de clef. Vous l'avez dit vous-même qu'il est impossible de trouver cela. Mais, tout n'est pas terminé puisqu'il y a la 'clef de session' finale à crypter par la phrase de passe.
J'essais de comprendre le pour et le contre de vos interventions. Car ce que vous faites concernant le clair, moi je l'analyse pour la clef et non seulement pour le clair. Mais, bien entendu je ne néglige pas le fait qu'e l'extension d'un nom de fichier peut suggérer l'entête. J'y réfléchi à cela aussi afin de rendre imprévisible le calcul de chiffrage (variant selon certaines valeurs de caractères).
Je suis présentement à faire des tests pour comprendre certaines différences de calculs et où les employer ou non. Exemple: un simple XOR offre plus de possibilité qu'un XOR avec une addition:
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
"((Valeur1 + Valeur1) xor Valeur2 ) = 164" donne 128 possibilités etc.
Je suis un débutant dans le domaine, je le reécris encore. Les spécialistes ont vu autant que moi que tes principes de base ne te permettent pas d'accéder à un niveau pourtant indispensable pour créer un algorithme de chiffrement modérément fiable. Des intervenants te l'ont dit en avance, mais j'ai préféré te le montrer directement de manière irréfutable.
Le 'TES' est de trop :-) pour la même raison plus haut. Je ne généralise pas.
... Faudrait que les calculs de l'algo soient imprévisibles dans son processus de chiffrement.
Et pourtant il faut tout de même déchiffrer.
Oui.
L'algorithme doit être connu de tous.
Oui.
Seules les clés peuvent être secrètes.
Et le clair dans mon cas: selon le principe de Vernam à 'masque jetable'.
L'attaque par force brute ne doit pas être exploitable, le temps pour casser un message par cette voie doit être trop grand par rapport aux enjeux.
Certainement.
L'algo ne doit pas présenter des faiblesses telles que celles indiquées pour le SA qui permettent d'avoir un calcul (quasiment) indépendant de la taille de la clé.
"Un calcul (quasiment) indépendant de la taille de la clé." Ceci n'est-il pas possible seulement en rapport avec un clair, un chiffré et un algo connu?
L'algorithme utilisé dans le 'simple algo' est faible, inutilisable. Il faut *changer* *totalement* de procédé.
Pas dans cette dernière étape avec juste un chiffré et un algo connu. Au dernier stade il peut être utilisable (mais il faut que je développe la partie transformant la clef de session finale en un code d'identification de la phrase de passe 'avec du xor': un nouvelle idée dont je viens d'avoir; car transmettre une clef de session finale à chaque fois cela n'est pas très commode) et n'est pas faible (selon décrit plus haut). Ici je n'oublie cependant pas le fait qu'il est possible que l'entête d'un fichier puisse être connu par l'extension de son nom. Je n'oublie pas non plus les répétitions dans un chiffré: par exemple avec un clair n'ayant que des caractères ascii zéro au début. C'est pourquoi je n'ai pas terminé de réfléchir à rendre imprévisible certains calculs de l'algo et non seulement la clef.
La sécurité par l'obscurité procure une sécurité très limitée.
D'accord.
Bonne journée r.h.
Christophe HENRY
Je suis présentement à faire des tests pour comprendre certaines différences de calculs et où les employer ou non. Exemple: un simple XOR offre plus de possibilité qu'un XOR avec une addition:
Un début d'excellente démarche :-) Il aurait fallu commencer par là.
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
Bon. Entropie optimale. S'inverse avec un seul calcul, tout comme la solution suivante, bien qu'elle "paraîsse" plus compliquée.
Histoire de préciser : (v1 + v1) xor v2 = c <=> (2*v1) xor v2 = c <=> (v1 shl 1) xor v2 = c <=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2 et : v1 = x shr 1 et v2 = v1 + 1
Bilan : 1 seul calcul pour trouver 2 solutions, au lieu de 128 ou 256.
Cela devrait t'indiquer l'idée de ma méthode.
faire un xor ou une addition reste une subsitution. La composée de deux substitutions reste une substitution.
Pas dans cette dernière étape avec juste un chiffré et un algo connu. Au dernier stade il peut être utilisable (mais il faut que je développe la ...
Hors spécifications, point de salut.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Je suis présentement à faire des tests pour comprendre certaines
différences de calculs et où les employer ou non. Exemple: un simple XOR
offre plus de possibilité qu'un XOR avec une addition:
Un début d'excellente démarche :-) Il aurait fallu commencer par là.
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
Bon. Entropie optimale. S'inverse avec un seul calcul, tout comme la
solution suivante, bien qu'elle "paraîsse" plus compliquée.
Je suis présentement à faire des tests pour comprendre certaines différences de calculs et où les employer ou non. Exemple: un simple XOR offre plus de possibilité qu'un XOR avec une addition:
Un début d'excellente démarche :-) Il aurait fallu commencer par là.
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
Bon. Entropie optimale. S'inverse avec un seul calcul, tout comme la solution suivante, bien qu'elle "paraîsse" plus compliquée.
Histoire de préciser : (v1 + v1) xor v2 = c <=> (2*v1) xor v2 = c <=> (v1 shl 1) xor v2 = c <=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2 et : v1 = x shr 1 et v2 = v1 + 1
Bilan : 1 seul calcul pour trouver 2 solutions, au lieu de 128 ou 256.
Cela devrait t'indiquer l'idée de ma méthode.
faire un xor ou une addition reste une subsitution. La composée de deux substitutions reste une substitution.
Pas dans cette dernière étape avec juste un chiffré et un algo connu. Au dernier stade il peut être utilisable (mais il faut que je développe la ...
Hors spécifications, point de salut.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
Noshi
On Sat, 22 Jan 2005 04:47:41 +0100, AMcD® wrote:
Noshi wrote:
On Thu, 20 Jan 2005 12:48:27 +0100, AMcD® wrote:
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non seulement ses maths foirent, mais sa programmation aussi. Et quand on utilise Visual Basic de surcroit... Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Ce que je voulais dire c'est que même si, par extraordinaire, il trouvait un algo valable, comme ce sera codé en VB ça ouvrira des portes supplémentaires pour craquer le truc encore plus vite. Pas l'algo en lui-même, mais le soft. Enfin, tant qu'il faut pas désassembler :-).
Ben a choisir je préfèrerais qu'il le fasse en java ;)
Je préférais CDP.
D'ailleurs, j'ai pas trop suivi la fin de l'épopée. Cela s'est terminé comment au fait, tu le sais ? Suicide, brevet international, fuite sur la lune ?
Aucune idée. Je viens épisodiquement quand y'a de l'animation. Je suppose que quelqu'un a démonté le soft avec un canif suisse et que ca a calmé le concepteur.
Tiens le jour ou je m'emmerde je fais un soft de crypto et je le publie ici sous un autre pseudo :)
-- Noshi
On Sat, 22 Jan 2005 04:47:41 +0100, AMcD® wrote:
Noshi wrote:
On Thu, 20 Jan 2005 12:48:27 +0100, AMcD® wrote:
Quand il aura une nouvelle version, moi ou d'autres lui
recraqueront, mais il ne comprendra toujours pas. Et cela pourra
durer ad vitam etaernam. Non seulement ses maths foirent, mais sa
programmation aussi. Et quand on utilise Visual Basic de surcroit...
Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Ce que je voulais dire c'est que même si, par extraordinaire, il trouvait un
algo valable, comme ce sera codé en VB ça ouvrira des portes supplémentaires
pour craquer le truc encore plus vite. Pas l'algo en lui-même, mais le soft.
Enfin, tant qu'il faut pas désassembler :-).
Ben a choisir je préfèrerais qu'il le fasse en java ;)
Je préférais CDP.
D'ailleurs, j'ai pas trop suivi la fin de l'épopée. Cela s'est terminé
comment au fait, tu le sais ? Suicide, brevet international, fuite sur la
lune ?
Aucune idée. Je viens épisodiquement quand y'a de l'animation. Je suppose
que quelqu'un a démonté le soft avec un canif suisse et que ca a calmé le
concepteur.
Tiens le jour ou je m'emmerde je fais un soft de crypto et je le publie ici
sous un autre pseudo :)
Quand il aura une nouvelle version, moi ou d'autres lui recraqueront, mais il ne comprendra toujours pas. Et cela pourra durer ad vitam etaernam. Non seulement ses maths foirent, mais sa programmation aussi. Et quand on utilise Visual Basic de surcroit... Bref, ce ne sont pas les points d'attaque qui font défaut :-).
Le visual basic n'a rien a voir dans le lot :)
Ce que je voulais dire c'est que même si, par extraordinaire, il trouvait un algo valable, comme ce sera codé en VB ça ouvrira des portes supplémentaires pour craquer le truc encore plus vite. Pas l'algo en lui-même, mais le soft. Enfin, tant qu'il faut pas désassembler :-).
Ben a choisir je préfèrerais qu'il le fasse en java ;)
Je préférais CDP.
D'ailleurs, j'ai pas trop suivi la fin de l'épopée. Cela s'est terminé comment au fait, tu le sais ? Suicide, brevet international, fuite sur la lune ?
Aucune idée. Je viens épisodiquement quand y'a de l'animation. Je suppose que quelqu'un a démonté le soft avec un canif suisse et que ca a calmé le concepteur.
Tiens le jour ou je m'emmerde je fais un soft de crypto et je le publie ici sous un autre pseudo :)
-- Noshi
Raymond H.
Bonjour,
"Christophe HENRY" a écrit dans le message de news: cstep6$14vd$
Je suis présentement à faire des tests pour comprendre certaines différences de calculs et où les employer ou non. Exemple: un simple XOR offre plus de possibilité qu'un XOR avec une addition:
Un début d'excellente démarche :-) Il aurait fallu commencer par là.
Disons qu'aux étapes 1, 2 et 3 j'essayais de trouver une façon pour empêcher une inversion de l'algo soit pour trouver la clef ou le clair. Mais après, parce que j'ai décidé de faire semblable à Vernam (masque jetable), j'ai dû modifier l'algo pour mettre l'accent sur la génération non prévisible de l'algo et simplifier le chiffrage du clair. J'en suis à réfléchir à cela maintenant.
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
Bon. Entropie optimale. S'inverse avec un seul calcul, tout comme la solution suivante, bien qu'elle "paraîsse" plus compliquée.
Histoire de préciser : (v1 + v1) xor v2 = c <=> (2*v1) xor v2 = c <=> (v1 shl 1) xor v2 = c <=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2 et : v1 = x shr 1 et v2 = v1 + 1
Bilan : 1 seul calcul pour trouver 2 solutions, au lieu de 128 ou 256.
Je comprends le SHL et le SHR pour le décalage binaire vers la gauche ou vers la droite, mais je ne suis pas vraiment votre logique ici. Il semble que nous ne parlons pas de la même chose, puisque vous parlez de trouver '2 solutions, au lieu de 128 ou 256'. Vous devriez arriver au même nombre de possibilités que moi pour une réponse donnée.
Ici, on essaie de savoir combien de combinaisons différentes (avec Valeur1 et Valeur2) peuvent donner '164'. Si on essaie tous les nombres possibles de 0 et 255 (ascii) soit pour Valeur1 ou pour Valeur2 et on aura 128 combinaisons qui donnent le nombre 164.
Bonne soirée
r.h.
N.B.: Voici quelques une des 128 possibilités pour la réponse 164 (je le fais en une seule boucle en VB): (000 + 000) Xor 164 = 164 (001 + 001) Xor 166 = 164 (002 + 002) Xor 160 = 164 (003 + 003) Xor 162 = 164 (004 + 004) Xor 172 = 164 (005 + 005) Xor 174 = 164 etc.
Bonjour,
"Christophe HENRY" <forumslkm.sbgodin@nerim.net.sans_lkm> a écrit dans le
message de news: cstep6$14vd$1@biggoron.nerim.net...
Je suis présentement à faire des tests pour comprendre certaines
différences de calculs et où les employer ou non. Exemple: un simple XOR
offre plus de possibilité qu'un XOR avec une addition:
Un début d'excellente démarche :-) Il aurait fallu commencer par là.
Disons qu'aux étapes 1, 2 et 3 j'essayais de trouver une façon pour
empêcher une inversion de l'algo soit pour trouver la clef ou le clair. Mais
après, parce que j'ai décidé de faire semblable à Vernam (masque jetable),
j'ai dû modifier l'algo pour mettre l'accent sur la génération non
prévisible de l'algo et simplifier le chiffrage du clair. J'en suis à
réfléchir à cela maintenant.
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
Bon. Entropie optimale. S'inverse avec un seul calcul, tout comme la
solution suivante, bien qu'elle "paraîsse" plus compliquée.
Histoire de préciser :
(v1 + v1) xor v2 = c
<=> (2*v1) xor v2 = c
<=> (v1 shl 1) xor v2 = c
<=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2
et : v1 = x shr 1 et v2 = v1 + 1
Bilan : 1 seul calcul pour trouver 2 solutions, au lieu de 128 ou 256.
Je comprends le SHL et le SHR pour le décalage binaire vers la gauche ou
vers la droite, mais je ne suis pas vraiment votre logique ici. Il semble
que nous ne parlons pas de la même chose, puisque vous parlez de trouver '2
solutions, au lieu de 128 ou 256'. Vous devriez arriver au même nombre de
possibilités que moi pour une réponse donnée.
Ici, on essaie de savoir combien de combinaisons différentes (avec
Valeur1 et Valeur2) peuvent donner '164'. Si on essaie tous les nombres
possibles de 0 et 255 (ascii) soit pour Valeur1 ou pour Valeur2 et on aura
128 combinaisons qui donnent le nombre 164.
Bonne soirée
r.h.
N.B.: Voici quelques une des 128 possibilités pour la réponse 164 (je le
fais en une seule boucle en VB):
(000 + 000) Xor 164 = 164
(001 + 001) Xor 166 = 164
(002 + 002) Xor 160 = 164
(003 + 003) Xor 162 = 164
(004 + 004) Xor 172 = 164
(005 + 005) Xor 174 = 164
etc.
"Christophe HENRY" a écrit dans le message de news: cstep6$14vd$
Je suis présentement à faire des tests pour comprendre certaines différences de calculs et où les employer ou non. Exemple: un simple XOR offre plus de possibilité qu'un XOR avec une addition:
Un début d'excellente démarche :-) Il aurait fallu commencer par là.
Disons qu'aux étapes 1, 2 et 3 j'essayais de trouver une façon pour empêcher une inversion de l'algo soit pour trouver la clef ou le clair. Mais après, parce que j'ai décidé de faire semblable à Vernam (masque jetable), j'ai dû modifier l'algo pour mettre l'accent sur la génération non prévisible de l'algo et simplifier le chiffrage du clair. J'en suis à réfléchir à cela maintenant.
"Valeur1 xor Valeur2 = 164" donne 256 possibilités
Bon. Entropie optimale. S'inverse avec un seul calcul, tout comme la solution suivante, bien qu'elle "paraîsse" plus compliquée.
Histoire de préciser : (v1 + v1) xor v2 = c <=> (2*v1) xor v2 = c <=> (v1 shl 1) xor v2 = c <=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2 et : v1 = x shr 1 et v2 = v1 + 1
Bilan : 1 seul calcul pour trouver 2 solutions, au lieu de 128 ou 256.
Je comprends le SHL et le SHR pour le décalage binaire vers la gauche ou vers la droite, mais je ne suis pas vraiment votre logique ici. Il semble que nous ne parlons pas de la même chose, puisque vous parlez de trouver '2 solutions, au lieu de 128 ou 256'. Vous devriez arriver au même nombre de possibilités que moi pour une réponse donnée.
Ici, on essaie de savoir combien de combinaisons différentes (avec Valeur1 et Valeur2) peuvent donner '164'. Si on essaie tous les nombres possibles de 0 et 255 (ascii) soit pour Valeur1 ou pour Valeur2 et on aura 128 combinaisons qui donnent le nombre 164.
Bonne soirée
r.h.
N.B.: Voici quelques une des 128 possibilités pour la réponse 164 (je le fais en une seule boucle en VB): (000 + 000) Xor 164 = 164 (001 + 001) Xor 166 = 164 (002 + 002) Xor 160 = 164 (003 + 003) Xor 162 = 164 (004 + 004) Xor 172 = 164 (005 + 005) Xor 174 = 164 etc.
Christophe HENRY
(v1 + v1) xor v2 = c <=> (2*v1) xor v2 = c <=> (v1 shl 1) xor v2 = c <=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2 et : x1 = x shr 1 et x2 = x1 xor 128
J'avais fais une erreur de calcul.
Je comprends le SHL et le SHR pour le décalage binaire vers la gauche ou vers la droite, mais je ne suis pas vraiment votre logique ici. Il semble que nous ne parlons pas de la même chose, puisque vous parlez de trouver '2 solutions, au lieu de 128 ou 256'. Vous devriez arriver au même nombre de possibilités que moi pour une réponse donnée.
J'y arrive aussi, avec une boucle sur 65536 itérations.
Pour toute équation de type "2*x xor 64 = 164" il y a deux solutions parfaitement liées.
Ainsi : (242 + 242) xor 64 = 164 ET (114 + 114) xor 64 = 164 Avec 114 = 242 xor 128.
pour résoudre "x xor 64 = 164", on a x8 ou x$2.
Ici, on essaie de savoir combien de combinaisons différentes (avec Valeur1 et Valeur2) peuvent donner '164'. Si on essaie tous les nombres possibles de 0 et 255 (ascii) soit pour Valeur1 ou pour Valeur2 et on aura 128 combinaisons qui donnent le nombre 164.
C'est un exemple de force brute. Tu parcours 65536 possibilités. J'utilise une méthode plus finaude : je n'en parcours que 256, pour ne m'intéresser qu'aux 128 nécessaires :
Pour i de 0 à 255 solution_1 = (164 xor i) shr 1 solution_2 = solution_1 xor 128 if (solution_1<=solution_2) affiche solution_1, solution_2 FPour
J'obtiens 128 sorties qui reprennent toutes les solutions.
On s'éloigne un peu de la cryptologie, là.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
(v1 + v1) xor v2 = c
<=> (2*v1) xor v2 = c
<=> (v1 shl 1) xor v2 = c
<=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2
et : x1 = x shr 1 et x2 = x1 xor 128
J'avais fais une erreur de calcul.
Je comprends le SHL et le SHR pour le décalage binaire vers la gauche ou
vers la droite, mais je ne suis pas vraiment votre logique ici. Il semble
que nous ne parlons pas de la même chose, puisque vous parlez de trouver '2
solutions, au lieu de 128 ou 256'. Vous devriez arriver au même nombre de
possibilités que moi pour une réponse donnée.
J'y arrive aussi, avec une boucle sur 65536 itérations.
Pour toute équation de type "2*x xor 64 = 164" il y a deux solutions
parfaitement liées.
Ainsi : (242 + 242) xor 64 = 164 ET (114 + 114) xor 64 = 164
Avec 114 = 242 xor 128.
pour résoudre "x xor 64 = 164", on a x8 ou x$2.
Ici, on essaie de savoir combien de combinaisons différentes (avec
Valeur1 et Valeur2) peuvent donner '164'. Si on essaie tous les nombres
possibles de 0 et 255 (ascii) soit pour Valeur1 ou pour Valeur2 et on
aura 128 combinaisons qui donnent le nombre 164.
C'est un exemple de force brute. Tu parcours 65536 possibilités.
J'utilise une méthode plus finaude : je n'en parcours que 256, pour ne
m'intéresser qu'aux 128 nécessaires :
Pour i de 0 à 255
solution_1 = (164 xor i) shr 1
solution_2 = solution_1 xor 128
if (solution_1<=solution_2) affiche solution_1, solution_2
FPour
J'obtiens 128 sorties qui reprennent toutes les solutions.
On s'éloigne un peu de la cryptologie, là.
--
Christophe HENRY
forumslkm.sbgodin@nerim.net (sans lkm)
GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
(v1 + v1) xor v2 = c <=> (2*v1) xor v2 = c <=> (v1 shl 1) xor v2 = c <=> x xor v2 = c sachant que x = v1 shl 1
De là, on trouve x : x = c xor v2 et : x1 = x shr 1 et x2 = x1 xor 128
J'avais fais une erreur de calcul.
Je comprends le SHL et le SHR pour le décalage binaire vers la gauche ou vers la droite, mais je ne suis pas vraiment votre logique ici. Il semble que nous ne parlons pas de la même chose, puisque vous parlez de trouver '2 solutions, au lieu de 128 ou 256'. Vous devriez arriver au même nombre de possibilités que moi pour une réponse donnée.
J'y arrive aussi, avec une boucle sur 65536 itérations.
Pour toute équation de type "2*x xor 64 = 164" il y a deux solutions parfaitement liées.
Ainsi : (242 + 242) xor 64 = 164 ET (114 + 114) xor 64 = 164 Avec 114 = 242 xor 128.
pour résoudre "x xor 64 = 164", on a x8 ou x$2.
Ici, on essaie de savoir combien de combinaisons différentes (avec Valeur1 et Valeur2) peuvent donner '164'. Si on essaie tous les nombres possibles de 0 et 255 (ascii) soit pour Valeur1 ou pour Valeur2 et on aura 128 combinaisons qui donnent le nombre 164.
C'est un exemple de force brute. Tu parcours 65536 possibilités. J'utilise une méthode plus finaude : je n'en parcours que 256, pour ne m'intéresser qu'aux 128 nécessaires :
Pour i de 0 à 255 solution_1 = (164 xor i) shr 1 solution_2 = solution_1 xor 128 if (solution_1<=solution_2) affiche solution_1, solution_2 FPour
J'obtiens 128 sorties qui reprennent toutes les solutions.
On s'éloigne un peu de la cryptologie, là.
-- Christophe HENRY (sans lkm) GnuPG : 3922239E60036EC86BF7268A877C52AC 4883C02A
