D'accord. Je veux travailler à faire un code pour chiffrer deux bmp, et
l'envoyer lorsqu'il sera prêt. Ainsi, l'entête cryptée y sera aussi.
Mais qui donnerait une même clef à plusieurs correspondants? Faire cela
avec peu importe le logiciel de chiffrage, ça serait du pareil au même. Ça
n'indique pas une vulnérabilité du logiciel lui-même mais de la clef dont
plusieurs auraient.
Mais par contre, si la phrase de passe (qui crypte la clef de session)
est transmisse à plus d'une personne à la fois, alors cela relèverait
de la responsabilité de l'envoyeur et ce serait la confiance envers
celui qui chiffre que le destinataire aurait à prendre le risque.
C'est comme ça avec tous les logiciels de chiffrage, à moins qu'il y
ait un procédé que je ne connais pas.
Donne-moi trois octet du clair, trois octet du chiffré, quelque soient
leurs longueurs et je te trouve la clé. Si ta clé fais N octets, ça
marche aussi avec N octets du clair et du chiffré.
J'avais déjà pensé qu'en faisant des tests aléatoirement en essayant
différents caractères au début du chiffré et de la clef de session, qu'il y
aurait matière à amélioration, justement à cause de cela. Je vais réfléchir
à cette logique au début du processus de chiffrement. Ensuite, je pourrais
vous envoyer les trois octets si je ne vois pas bien comment il est possible
en peu de temps de cryptanalyser cela.
D'accord. Je veux travailler à faire un code pour chiffrer deux bmp, et
l'envoyer lorsqu'il sera prêt. Ainsi, l'entête cryptée y sera aussi.
Mais qui donnerait une même clef à plusieurs correspondants? Faire cela
avec peu importe le logiciel de chiffrage, ça serait du pareil au même. Ça
n'indique pas une vulnérabilité du logiciel lui-même mais de la clef dont
plusieurs auraient.
Mais par contre, si la phrase de passe (qui crypte la clef de session)
est transmisse à plus d'une personne à la fois, alors cela relèverait
de la responsabilité de l'envoyeur et ce serait la confiance envers
celui qui chiffre que le destinataire aurait à prendre le risque.
C'est comme ça avec tous les logiciels de chiffrage, à moins qu'il y
ait un procédé que je ne connais pas.
Donne-moi trois octet du clair, trois octet du chiffré, quelque soient
leurs longueurs et je te trouve la clé. Si ta clé fais N octets, ça
marche aussi avec N octets du clair et du chiffré.
J'avais déjà pensé qu'en faisant des tests aléatoirement en essayant
différents caractères au début du chiffré et de la clef de session, qu'il y
aurait matière à amélioration, justement à cause de cela. Je vais réfléchir
à cette logique au début du processus de chiffrement. Ensuite, je pourrais
vous envoyer les trois octets si je ne vois pas bien comment il est possible
en peu de temps de cryptanalyser cela.
D'accord. Je veux travailler à faire un code pour chiffrer deux bmp, et
l'envoyer lorsqu'il sera prêt. Ainsi, l'entête cryptée y sera aussi.
Mais qui donnerait une même clef à plusieurs correspondants? Faire cela
avec peu importe le logiciel de chiffrage, ça serait du pareil au même. Ça
n'indique pas une vulnérabilité du logiciel lui-même mais de la clef dont
plusieurs auraient.
Mais par contre, si la phrase de passe (qui crypte la clef de session)
est transmisse à plus d'une personne à la fois, alors cela relèverait
de la responsabilité de l'envoyeur et ce serait la confiance envers
celui qui chiffre que le destinataire aurait à prendre le risque.
C'est comme ça avec tous les logiciels de chiffrage, à moins qu'il y
ait un procédé que je ne connais pas.
Donne-moi trois octet du clair, trois octet du chiffré, quelque soient
leurs longueurs et je te trouve la clé. Si ta clé fais N octets, ça
marche aussi avec N octets du clair et du chiffré.
J'avais déjà pensé qu'en faisant des tests aléatoirement en essayant
différents caractères au début du chiffré et de la clef de session, qu'il y
aurait matière à amélioration, justement à cause de cela. Je vais réfléchir
à cette logique au début du processus de chiffrement. Ensuite, je pourrais
vous envoyer les trois octets si je ne vois pas bien comment il est possible
en peu de temps de cryptanalyser cela.
Il ne peut pas y avoir d'attaque à partir du clair, puisque vous ne
connaissez pas le clair et c'est le clair qui construit la clef de session
et ça prend la clef de session pour déchiffrer le chiffré pour trouver le
clair.
De même on ne peut pas vraiment appeler 'attaque à clair connu' une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une seule
fois: 'masque jetable'.
Et de plus je veux simplifier la partie de l'algo qui crypte le clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Cependant, il semble qu'une attaque à clair connu soit impossible (je ne
parle pas d'attaque à force brute). Pourrait-on confirmer cette affirmation
avec l'exemple suivant (selon l'étape 3)?
De quelle façon saurait-on que l'image est en JPEG? Par répétition d'une
même couleur ou de l'entête indiquant le type de fichier?
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
D'accord. Faudrait dans ce cas que je crée un petit programme pour le
faire sinon autrement ça va être trop long. Je pourrait ainsi vous envoyer
deux petits bmp, et l'entête y serait du même coup. L'un des deux serait
quelques couleurs simple qui se répètent: cela pourrait vous faciliter les
choses. C'est ok?
Vous ne voulez pas plutôt dire: "Il y AURAIT de l'information..."?
Sinon, je ne comprends pas puisqu'il n'existe pas de caractères hors de
cette plage (0-255). Ça peut être n'importe lesquels des caractères de 0 à
255 puisque la clef de session initiale serait générée aléatoirement par le
logiciel.
Mais je ne pense pas vraiment qu'on puisse chercher par fréquences de
caractère puisqu'un même caractère n'a pas nécessairement la même valeur
d'un endroit à l'autre, à cause du calcul de l'algo. Tantôt un P pourrait
être calculé (via addition et xor) à partir de certaines valeurs et tantôt
par d'autres valeurs.
Je ne pense pas vraiment qu'on puisse procéder par
statistique. Si vous voulez, dans AllCrypter il y a le 4e onglet qui donne
automatiquement les fréquences de chaque caractère qui se retrouve dans le
texte de sa fenêtre de gauche.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
D'accord.
Il ne peut pas y avoir d'attaque à partir du clair, puisque vous ne
connaissez pas le clair et c'est le clair qui construit la clef de session
et ça prend la clef de session pour déchiffrer le chiffré pour trouver le
clair.
De même on ne peut pas vraiment appeler 'attaque à clair connu' une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une seule
fois: 'masque jetable'.
Et de plus je veux simplifier la partie de l'algo qui crypte le clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Cependant, il semble qu'une attaque à clair connu soit impossible (je ne
parle pas d'attaque à force brute). Pourrait-on confirmer cette affirmation
avec l'exemple suivant (selon l'étape 3)?
De quelle façon saurait-on que l'image est en JPEG? Par répétition d'une
même couleur ou de l'entête indiquant le type de fichier?
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
D'accord. Faudrait dans ce cas que je crée un petit programme pour le
faire sinon autrement ça va être trop long. Je pourrait ainsi vous envoyer
deux petits bmp, et l'entête y serait du même coup. L'un des deux serait
quelques couleurs simple qui se répètent: cela pourrait vous faciliter les
choses. C'est ok?
Vous ne voulez pas plutôt dire: "Il y AURAIT de l'information..."?
Sinon, je ne comprends pas puisqu'il n'existe pas de caractères hors de
cette plage (0-255). Ça peut être n'importe lesquels des caractères de 0 à
255 puisque la clef de session initiale serait générée aléatoirement par le
logiciel.
Mais je ne pense pas vraiment qu'on puisse chercher par fréquences de
caractère puisqu'un même caractère n'a pas nécessairement la même valeur
d'un endroit à l'autre, à cause du calcul de l'algo. Tantôt un P pourrait
être calculé (via addition et xor) à partir de certaines valeurs et tantôt
par d'autres valeurs.
Je ne pense pas vraiment qu'on puisse procéder par
statistique. Si vous voulez, dans AllCrypter il y a le 4e onglet qui donne
automatiquement les fréquences de chaque caractère qui se retrouve dans le
texte de sa fenêtre de gauche.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
D'accord.
Il ne peut pas y avoir d'attaque à partir du clair, puisque vous ne
connaissez pas le clair et c'est le clair qui construit la clef de session
et ça prend la clef de session pour déchiffrer le chiffré pour trouver le
clair.
De même on ne peut pas vraiment appeler 'attaque à clair connu' une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une seule
fois: 'masque jetable'.
Et de plus je veux simplifier la partie de l'algo qui crypte le clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Cependant, il semble qu'une attaque à clair connu soit impossible (je ne
parle pas d'attaque à force brute). Pourrait-on confirmer cette affirmation
avec l'exemple suivant (selon l'étape 3)?
De quelle façon saurait-on que l'image est en JPEG? Par répétition d'une
même couleur ou de l'entête indiquant le type de fichier?
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
D'accord. Faudrait dans ce cas que je crée un petit programme pour le
faire sinon autrement ça va être trop long. Je pourrait ainsi vous envoyer
deux petits bmp, et l'entête y serait du même coup. L'un des deux serait
quelques couleurs simple qui se répètent: cela pourrait vous faciliter les
choses. C'est ok?
Vous ne voulez pas plutôt dire: "Il y AURAIT de l'information..."?
Sinon, je ne comprends pas puisqu'il n'existe pas de caractères hors de
cette plage (0-255). Ça peut être n'importe lesquels des caractères de 0 à
255 puisque la clef de session initiale serait générée aléatoirement par le
logiciel.
Mais je ne pense pas vraiment qu'on puisse chercher par fréquences de
caractère puisqu'un même caractère n'a pas nécessairement la même valeur
d'un endroit à l'autre, à cause du calcul de l'algo. Tantôt un P pourrait
être calculé (via addition et xor) à partir de certaines valeurs et tantôt
par d'autres valeurs.
Je ne pense pas vraiment qu'on puisse procéder par
statistique. Si vous voulez, dans AllCrypter il y a le 4e onglet qui donne
automatiquement les fréquences de chaque caractère qui se retrouve dans le
texte de sa fenêtre de gauche.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
D'accord.
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Il ne peut pas y avoir d'attaque à partir du clair, puisque vous ne
connaissez pas le clair et c'est le clair qui construit la clef de
session
Ce n'est donc pas une clé de session conventionnelle. Une clé de session
est par définition indépendante des données à chiffrer.
et ça prend la clef de session pour déchiffrer le chiffré pour trouver le
clair. De même on ne peut pas vraiment appeler 'attaque à clair connu'
une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une
seule
fois: 'masque jetable'.
Effectivement, dans cet optique-là, il est inutile d'aller plus loin :
l'étape 3 du simple algo suffit à blinder toutes données chiffrées.
Les soucis proviennent des réutilisations des clés ou des redondances
induites par le chiffrement. Et la version actuelle, avec "clé de
session", se trouve dans ce cas.Le problème serait plutôt de trouver le clair.
Dans cette étape 4, c'est le but, puisque la clef de session est un
'masque
jetable'; elle ne sert qu'une seule fois, même si on chiffre plusieurs
fois
le même fichier.
Le masque jetable, dans son principe, fait appel à une clé (qui n'est
pas de session, d'ailleurs) générée aléatoirement, qui occupe tout
l'espace des clés et qui est, par déduction, indépendant de tout clair
à chiffrer.
Et de plus je veux simplifier la partie de l'algo qui crypte le
clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Pourquoi placer un "x+1" ? Avec un "x" tout court, c'est plus lisible :
c_x = ((( k_1 + m_x+1) xor m_1) +k_1) % 256
Tu es sûr que tu veux conserver le m_1 après le xor ?! J'aurais opté
pour m_x. Mais cela ne change rien aux conséquences.
Cela pour tenter d'empêcher les attaques à force brute à partir
d'une clef de session (et non de la phrase de passe).
Nous en sommes par encore là. Jack et moi avons attaqué ton algorithme
avec une variante de l'algorithme du simplex. Pour faire imagé, c'est un
parcours dans un genre de polyèdre multidimensionnel représentant les
chiffrés pour optimiser une fonction. La fonction, ici, c'est de trouver
la clé. Le grand jeu est de croiser des sous-espaces vectoriels de
l'espaces des clés :-o
Le hic, c'est qu'il y a plein de trous causés par le cumul de l'addition
et du xor, mais bon...
Selon l'étape 3, donc:
c1 = (((k1 + m1) xor k1) + k1) Modulo 256
c2 = (((k2 + m2) xor k2) + k2) Modulo 256
c3 = (((k3 + m3) xor k3) + k3) Modulo 256
J'ai fait le test avec:
c = 010-024-036
m = 008-012-021
et la seule clef possible est
k = 002-004-005
Cependant, il semble qu'une attaque à clair connu soit impossible
(je ne parle pas d'attaque à force brute). Pourrait-on confirmer cette
affirmation avec l'exemple suivant (selon l'étape 3)?
Clef: ? - ? - ?
Clair: 008-012-021
Chiffré: 132-070-010
Dans ce domaine, il vaut mieux que "il semble" ne soit pas envisagé. Il
faudrait _démontrer_ :
K=[108,42,223] unique.
De quelle façon saurait-on que l'image est en JPEG? Par
répétition d'une même couleur ou de l'entête indiquant le type de
fichier ?
Oui, car on aurait des renseignements sur le clair. En particulier, les
premiers octets du fichier.
Ça peut être n'importe lesquels des caractères
de 0 à 255 puisque la clef de session initiale serait générée
aléatoirement par le logiciel.
_serait_ : sans projet clair, pas de réponse claire.
Ici, je n'ose pas parler d'OTP qui
signifie 'One Time Password'
One Time Pad.
Mais je ne pense pas vraiment qu'on puisse chercher par fréquences
de caractère puisqu'un même caractère n'a pas nécessairement la même
valeur d'un endroit à l'autre, à cause du calcul de l'algo. Tantôt
un P pourrait être calculé (via addition et xor) à partir de
certaines valeurs et tantôt par d'autres valeurs. Je ne pense pas
vraiment qu'on puisse procéder par statistique.
Tu penses, mais d'autres savent. La littérature actuelle est remplie
d'exemples de ce type. Et encore, ni Jack ni moi avons mis en avant les
procédés modernes de cryptanalyse.
Les livres te feraient de meilleurs interlocuteurs que nous. Mais c'est
tout de même amusant de continuer sur notre lancée ;-)
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Il ne peut pas y avoir d'attaque à partir du clair, puisque vous ne
connaissez pas le clair et c'est le clair qui construit la clef de
session
Ce n'est donc pas une clé de session conventionnelle. Une clé de session
est par définition indépendante des données à chiffrer.
et ça prend la clef de session pour déchiffrer le chiffré pour trouver le
clair. De même on ne peut pas vraiment appeler 'attaque à clair connu'
une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une
seule
fois: 'masque jetable'.
Effectivement, dans cet optique-là, il est inutile d'aller plus loin :
l'étape 3 du simple algo suffit à blinder toutes données chiffrées.
Les soucis proviennent des réutilisations des clés ou des redondances
induites par le chiffrement. Et la version actuelle, avec "clé de
session", se trouve dans ce cas.
Le problème serait plutôt de trouver le clair.
Dans cette étape 4, c'est le but, puisque la clef de session est un
'masque
jetable'; elle ne sert qu'une seule fois, même si on chiffre plusieurs
fois
le même fichier.
Le masque jetable, dans son principe, fait appel à une clé (qui n'est
pas de session, d'ailleurs) générée aléatoirement, qui occupe tout
l'espace des clés et qui est, par déduction, indépendant de tout clair
à chiffrer.
Et de plus je veux simplifier la partie de l'algo qui crypte le
clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Pourquoi placer un "x+1" ? Avec un "x" tout court, c'est plus lisible :
c_x = ((( k_1 + m_x+1) xor m_1) +k_1) % 256
Tu es sûr que tu veux conserver le m_1 après le xor ?! J'aurais opté
pour m_x. Mais cela ne change rien aux conséquences.
Cela pour tenter d'empêcher les attaques à force brute à partir
d'une clef de session (et non de la phrase de passe).
Nous en sommes par encore là. Jack et moi avons attaqué ton algorithme
avec une variante de l'algorithme du simplex. Pour faire imagé, c'est un
parcours dans un genre de polyèdre multidimensionnel représentant les
chiffrés pour optimiser une fonction. La fonction, ici, c'est de trouver
la clé. Le grand jeu est de croiser des sous-espaces vectoriels de
l'espaces des clés :-o
Le hic, c'est qu'il y a plein de trous causés par le cumul de l'addition
et du xor, mais bon...
Selon l'étape 3, donc:
c1 = (((k1 + m1) xor k1) + k1) Modulo 256
c2 = (((k2 + m2) xor k2) + k2) Modulo 256
c3 = (((k3 + m3) xor k3) + k3) Modulo 256
J'ai fait le test avec:
c = 010-024-036
m = 008-012-021
et la seule clef possible est
k = 002-004-005
Cependant, il semble qu'une attaque à clair connu soit impossible
(je ne parle pas d'attaque à force brute). Pourrait-on confirmer cette
affirmation avec l'exemple suivant (selon l'étape 3)?
Clef: ? - ? - ?
Clair: 008-012-021
Chiffré: 132-070-010
Dans ce domaine, il vaut mieux que "il semble" ne soit pas envisagé. Il
faudrait _démontrer_ :
K=[108,42,223] unique.
De quelle façon saurait-on que l'image est en JPEG? Par
répétition d'une même couleur ou de l'entête indiquant le type de
fichier ?
Oui, car on aurait des renseignements sur le clair. En particulier, les
premiers octets du fichier.
Ça peut être n'importe lesquels des caractères
de 0 à 255 puisque la clef de session initiale serait générée
aléatoirement par le logiciel.
_serait_ : sans projet clair, pas de réponse claire.
Ici, je n'ose pas parler d'OTP qui
signifie 'One Time Password'
One Time Pad.
Mais je ne pense pas vraiment qu'on puisse chercher par fréquences
de caractère puisqu'un même caractère n'a pas nécessairement la même
valeur d'un endroit à l'autre, à cause du calcul de l'algo. Tantôt
un P pourrait être calculé (via addition et xor) à partir de
certaines valeurs et tantôt par d'autres valeurs. Je ne pense pas
vraiment qu'on puisse procéder par statistique.
Tu penses, mais d'autres savent. La littérature actuelle est remplie
d'exemples de ce type. Et encore, ni Jack ni moi avons mis en avant les
procédés modernes de cryptanalyse.
Les livres te feraient de meilleurs interlocuteurs que nous. Mais c'est
tout de même amusant de continuer sur notre lancée ;-)
Après avoir un peu testé l'algo, je dois dire que cette attaque à clair
connu est démonstrative de la faiblesse de l'algo.
Il ne peut pas y avoir d'attaque à partir du clair, puisque vous ne
connaissez pas le clair et c'est le clair qui construit la clef de
session
Ce n'est donc pas une clé de session conventionnelle. Une clé de session
est par définition indépendante des données à chiffrer.
et ça prend la clef de session pour déchiffrer le chiffré pour trouver le
clair. De même on ne peut pas vraiment appeler 'attaque à clair connu'
une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une
seule
fois: 'masque jetable'.
Effectivement, dans cet optique-là, il est inutile d'aller plus loin :
l'étape 3 du simple algo suffit à blinder toutes données chiffrées.
Les soucis proviennent des réutilisations des clés ou des redondances
induites par le chiffrement. Et la version actuelle, avec "clé de
session", se trouve dans ce cas.Le problème serait plutôt de trouver le clair.
Dans cette étape 4, c'est le but, puisque la clef de session est un
'masque
jetable'; elle ne sert qu'une seule fois, même si on chiffre plusieurs
fois
le même fichier.
Le masque jetable, dans son principe, fait appel à une clé (qui n'est
pas de session, d'ailleurs) générée aléatoirement, qui occupe tout
l'espace des clés et qui est, par déduction, indépendant de tout clair
à chiffrer.
Et de plus je veux simplifier la partie de l'algo qui crypte le
clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Pourquoi placer un "x+1" ? Avec un "x" tout court, c'est plus lisible :
c_x = ((( k_1 + m_x+1) xor m_1) +k_1) % 256
Tu es sûr que tu veux conserver le m_1 après le xor ?! J'aurais opté
pour m_x. Mais cela ne change rien aux conséquences.
Cela pour tenter d'empêcher les attaques à force brute à partir
d'une clef de session (et non de la phrase de passe).
Nous en sommes par encore là. Jack et moi avons attaqué ton algorithme
avec une variante de l'algorithme du simplex. Pour faire imagé, c'est un
parcours dans un genre de polyèdre multidimensionnel représentant les
chiffrés pour optimiser une fonction. La fonction, ici, c'est de trouver
la clé. Le grand jeu est de croiser des sous-espaces vectoriels de
l'espaces des clés :-o
Le hic, c'est qu'il y a plein de trous causés par le cumul de l'addition
et du xor, mais bon...
Selon l'étape 3, donc:
c1 = (((k1 + m1) xor k1) + k1) Modulo 256
c2 = (((k2 + m2) xor k2) + k2) Modulo 256
c3 = (((k3 + m3) xor k3) + k3) Modulo 256
J'ai fait le test avec:
c = 010-024-036
m = 008-012-021
et la seule clef possible est
k = 002-004-005
Cependant, il semble qu'une attaque à clair connu soit impossible
(je ne parle pas d'attaque à force brute). Pourrait-on confirmer cette
affirmation avec l'exemple suivant (selon l'étape 3)?
Clef: ? - ? - ?
Clair: 008-012-021
Chiffré: 132-070-010
Dans ce domaine, il vaut mieux que "il semble" ne soit pas envisagé. Il
faudrait _démontrer_ :
K=[108,42,223] unique.
De quelle façon saurait-on que l'image est en JPEG? Par
répétition d'une même couleur ou de l'entête indiquant le type de
fichier ?
Oui, car on aurait des renseignements sur le clair. En particulier, les
premiers octets du fichier.
Ça peut être n'importe lesquels des caractères
de 0 à 255 puisque la clef de session initiale serait générée
aléatoirement par le logiciel.
_serait_ : sans projet clair, pas de réponse claire.
Ici, je n'ose pas parler d'OTP qui
signifie 'One Time Password'
One Time Pad.
Mais je ne pense pas vraiment qu'on puisse chercher par fréquences
de caractère puisqu'un même caractère n'a pas nécessairement la même
valeur d'un endroit à l'autre, à cause du calcul de l'algo. Tantôt
un P pourrait être calculé (via addition et xor) à partir de
certaines valeurs et tantôt par d'autres valeurs. Je ne pense pas
vraiment qu'on puisse procéder par statistique.
Tu penses, mais d'autres savent. La littérature actuelle est remplie
d'exemples de ce type. Et encore, ni Jack ni moi avons mis en avant les
procédés modernes de cryptanalyse.
Les livres te feraient de meilleurs interlocuteurs que nous. Mais c'est
tout de même amusant de continuer sur notre lancée ;-)
De même on ne peut pas vraiment appeler 'attaque à clair connu' une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une
seule fois: 'masque jetable'.
Un masque jetable, si je ne me trompe pas :
- Est utilisé une seule fois.
- Est de la même longueur que le message.
- Est d'entropie maximale
L'usage unique serait possible avec Allcrypter, mais dans la pratique
c'est une autre histoire. Pour la longueur et l'entropie vous êtes loin du
compte. La clé de session (comme vous l'appelez) est générée à partir d'un
germe et du clair... Elle n'est donc pas d'entropie maximale, même si vous
chiffrez un bruit blanc. Et pour la longueur... elle a beau être
physiquement la même que celle du message, on pourrait dire qu'elle est
virtuellement plus courte, de part sa méthode de génération.
Et de plus je veux simplifier la partie de l'algo qui crypte le
clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Pffff.... les retouches homéopatiques ne servent à RIEN ! A chaque fois
vous obligez ceux qui veulent vous aider (ou vous faire ouvrir les yeux,
pour ma part) à reculer d'un pas pour réavancer aussitôt... c'est
inutile...
Cependant, il semble qu'une attaque à clair connu soit impossible (je
ne parle pas d'attaque à force brute). Pourrait-on confirmer cette
affirmation avec l'exemple suivant (selon l'étape 3)?
Vous pensez trop ou trop peu, c'est selon. Si personne ne prend au sérieux
votre "travail", il y a des raisons. Pour quelqu'un qui touche même un
tout petit peu en cryptologie (?), votre algo apparait faible au premier
regard.
De quelle façon saurait-on que l'image est en JPEG? Par répétition
d'une même couleur ou de l'entête indiquant le type de fichier?
Si vous êtes sous Windows, avec l'extension du fichier, on a rapidement
une bonne idée de ce que vous envoyez. Et si retirez l'extension du
fichier, votre correspondant aura des difficultés à l'utiliser (sous
Windows).
Restera donc à ajouter le nom du fichier au clair... mais là, étant
données les limitations importantes sur les noms de fichiers, vous
fournissez de l'information sur le clair... donc... pas bon. toc.
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
D'accord. Faudrait dans ce cas que je crée un petit programme pour
le faire sinon autrement ça va être trop long. Je pourrait ainsi vous
envoyer deux petits bmp, et l'entête y serait du même coup. L'un des
deux serait quelques couleurs simple qui se répètent: cela pourrait vous
faciliter les choses. C'est ok?
Non, c'est pas Ok... je vais pas passer mon temps à vous montrer par a+b
que votre algo ne tient pas. Vous n'avez eu que des commentaires négatifs
sur votre algo, et il y a une raison : il est faible, c'est tout.
Je ne vais pas passer mon temps à réduire en bouillie les fichiers que
vous générez pour la beauté de l'art.
Je vous rappelle que même avec un truc faiblard comme le votre il faut
passer du temps pour le casser... et comme le disait AMcD, on n'est pas
payé pour ça.
En l'état, je prends des vacances, et vous laisse vous amuser tout seul.
JE veux bien commenter sans être entendu (j'ai l'habitude), mais pas faire
du boulot inutilement.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
D'accord.
De même on ne peut pas vraiment appeler 'attaque à clair connu' une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une
seule fois: 'masque jetable'.
Un masque jetable, si je ne me trompe pas :
- Est utilisé une seule fois.
- Est de la même longueur que le message.
- Est d'entropie maximale
L'usage unique serait possible avec Allcrypter, mais dans la pratique
c'est une autre histoire. Pour la longueur et l'entropie vous êtes loin du
compte. La clé de session (comme vous l'appelez) est générée à partir d'un
germe et du clair... Elle n'est donc pas d'entropie maximale, même si vous
chiffrez un bruit blanc. Et pour la longueur... elle a beau être
physiquement la même que celle du message, on pourrait dire qu'elle est
virtuellement plus courte, de part sa méthode de génération.
Et de plus je veux simplifier la partie de l'algo qui crypte le
clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Pffff.... les retouches homéopatiques ne servent à RIEN ! A chaque fois
vous obligez ceux qui veulent vous aider (ou vous faire ouvrir les yeux,
pour ma part) à reculer d'un pas pour réavancer aussitôt... c'est
inutile...
Cependant, il semble qu'une attaque à clair connu soit impossible (je
ne parle pas d'attaque à force brute). Pourrait-on confirmer cette
affirmation avec l'exemple suivant (selon l'étape 3)?
Vous pensez trop ou trop peu, c'est selon. Si personne ne prend au sérieux
votre "travail", il y a des raisons. Pour quelqu'un qui touche même un
tout petit peu en cryptologie (?), votre algo apparait faible au premier
regard.
De quelle façon saurait-on que l'image est en JPEG? Par répétition
d'une même couleur ou de l'entête indiquant le type de fichier?
Si vous êtes sous Windows, avec l'extension du fichier, on a rapidement
une bonne idée de ce que vous envoyez. Et si retirez l'extension du
fichier, votre correspondant aura des difficultés à l'utiliser (sous
Windows).
Restera donc à ajouter le nom du fichier au clair... mais là, étant
données les limitations importantes sur les noms de fichiers, vous
fournissez de l'information sur le clair... donc... pas bon. toc.
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
D'accord. Faudrait dans ce cas que je crée un petit programme pour
le faire sinon autrement ça va être trop long. Je pourrait ainsi vous
envoyer deux petits bmp, et l'entête y serait du même coup. L'un des
deux serait quelques couleurs simple qui se répètent: cela pourrait vous
faciliter les choses. C'est ok?
Non, c'est pas Ok... je vais pas passer mon temps à vous montrer par a+b
que votre algo ne tient pas. Vous n'avez eu que des commentaires négatifs
sur votre algo, et il y a une raison : il est faible, c'est tout.
Je ne vais pas passer mon temps à réduire en bouillie les fichiers que
vous générez pour la beauté de l'art.
Je vous rappelle que même avec un truc faiblard comme le votre il faut
passer du temps pour le casser... et comme le disait AMcD, on n'est pas
payé pour ça.
En l'état, je prends des vacances, et vous laisse vous amuser tout seul.
JE veux bien commenter sans être entendu (j'ai l'habitude), mais pas faire
du boulot inutilement.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
D'accord.
De même on ne peut pas vraiment appeler 'attaque à clair connu' une
attaque avec le principe de Vernam puisqu'il n'utilise la clef qu'une
seule fois: 'masque jetable'.
Un masque jetable, si je ne me trompe pas :
- Est utilisé une seule fois.
- Est de la même longueur que le message.
- Est d'entropie maximale
L'usage unique serait possible avec Allcrypter, mais dans la pratique
c'est une autre histoire. Pour la longueur et l'entropie vous êtes loin du
compte. La clé de session (comme vous l'appelez) est générée à partir d'un
germe et du clair... Elle n'est donc pas d'entropie maximale, même si vous
chiffrez un bruit blanc. Et pour la longueur... elle a beau être
physiquement la même que celle du message, on pourrait dire qu'elle est
virtuellement plus courte, de part sa méthode de génération.
Et de plus je veux simplifier la partie de l'algo qui crypte le
clair:
par exemple enlever cette ligne-ci
"c(x+1) = (((k1 + m(x+1)) xor k2) + k1) Modulo 256"
pour la remplacer par celle-ci
"c(x+1) = (((k1 + m(x+1)) xor m1) + k1) Modulo 256"
Pffff.... les retouches homéopatiques ne servent à RIEN ! A chaque fois
vous obligez ceux qui veulent vous aider (ou vous faire ouvrir les yeux,
pour ma part) à reculer d'un pas pour réavancer aussitôt... c'est
inutile...
Cependant, il semble qu'une attaque à clair connu soit impossible (je
ne parle pas d'attaque à force brute). Pourrait-on confirmer cette
affirmation avec l'exemple suivant (selon l'étape 3)?
Vous pensez trop ou trop peu, c'est selon. Si personne ne prend au sérieux
votre "travail", il y a des raisons. Pour quelqu'un qui touche même un
tout petit peu en cryptologie (?), votre algo apparait faible au premier
regard.
De quelle façon saurait-on que l'image est en JPEG? Par répétition
d'une même couleur ou de l'entête indiquant le type de fichier?
Si vous êtes sous Windows, avec l'extension du fichier, on a rapidement
une bonne idée de ce que vous envoyez. Et si retirez l'extension du
fichier, votre correspondant aura des difficultés à l'utiliser (sous
Windows).
Restera donc à ajouter le nom du fichier au clair... mais là, étant
données les limitations importantes sur les noms de fichiers, vous
fournissez de l'information sur le clair... donc... pas bon. toc.
Par contre, si vous nous donnez une image BMP de taille raisonnable
chiffrée avec une clé de session compréhensible par son auteur, alors là,
oui, on peut faire quelque chose.
D'accord. Faudrait dans ce cas que je crée un petit programme pour
le faire sinon autrement ça va être trop long. Je pourrait ainsi vous
envoyer deux petits bmp, et l'entête y serait du même coup. L'un des
deux serait quelques couleurs simple qui se répètent: cela pourrait vous
faciliter les choses. C'est ok?
Non, c'est pas Ok... je vais pas passer mon temps à vous montrer par a+b
que votre algo ne tient pas. Vous n'avez eu que des commentaires négatifs
sur votre algo, et il y a une raison : il est faible, c'est tout.
Je ne vais pas passer mon temps à réduire en bouillie les fichiers que
vous générez pour la beauté de l'art.
Je vous rappelle que même avec un truc faiblard comme le votre il faut
passer du temps pour le casser... et comme le disait AMcD, on n'est pas
payé pour ça.
En l'état, je prends des vacances, et vous laisse vous amuser tout seul.
JE veux bien commenter sans être entendu (j'ai l'habitude), mais pas faire
du boulot inutilement.
Pensez à vous mettre dans un cas d'utilisation normale de votre algo...
D'accord.
Le hic, c'est qu'il y a plein de trous causés par le cumul de l'addition
et du xor, mais bon...
Les trous sont une bonne chose dans ce contexte?
K=[108,42,223] unique.
Lorsque je parlais d'attaque à clair connu, j'excluais le fait d'essayer
plusieurs clefs jusqu'à trouver la bonne. Est-ce de cette façon que vous
l'avez trouvée (même si c'est dans votre code)?
Car sinon, je ne comprends pas comment vous puissiez trouver cela à
moins de faire des tests par des itérations ou des essais.
Et ensuite, vous faites plusieurs essais de clefs différentes
jusqu'à ce que vous tombiez sur la bonne? C'est bien juste ça?
Le hic, c'est qu'il y a plein de trous causés par le cumul de l'addition
et du xor, mais bon...
Les trous sont une bonne chose dans ce contexte?
K=[108,42,223] unique.
Lorsque je parlais d'attaque à clair connu, j'excluais le fait d'essayer
plusieurs clefs jusqu'à trouver la bonne. Est-ce de cette façon que vous
l'avez trouvée (même si c'est dans votre code)?
Car sinon, je ne comprends pas comment vous puissiez trouver cela à
moins de faire des tests par des itérations ou des essais.
Et ensuite, vous faites plusieurs essais de clefs différentes
jusqu'à ce que vous tombiez sur la bonne? C'est bien juste ça?
Le hic, c'est qu'il y a plein de trous causés par le cumul de l'addition
et du xor, mais bon...
Les trous sont une bonne chose dans ce contexte?
K=[108,42,223] unique.
Lorsque je parlais d'attaque à clair connu, j'excluais le fait d'essayer
plusieurs clefs jusqu'à trouver la bonne. Est-ce de cette façon que vous
l'avez trouvée (même si c'est dans votre code)?
Car sinon, je ne comprends pas comment vous puissiez trouver cela à
moins de faire des tests par des itérations ou des essais.
Et ensuite, vous faites plusieurs essais de clefs différentes
jusqu'à ce que vous tombiez sur la bonne? C'est bien juste ça?
J'ai déjà dis que je ne m'arrêtera pas parce des gens me disent ceci ou
cela. Moi je crois que je peux réaliser un algo incassable et je fonce.
Mais chaque étape en son temps. Dans cette étape-ci il y a
plusieurs sous étapes et j'en suis qu'à la 1re. Le fait de savoir si
on peut ou non trouver le clair à partir du chiffré et l'algo, mais
sans faire de force brute ou essayer des clefs différentes jusqu'à
trouver le clair qui correspond au chiffré.
J'ai déjà dis que je ne m'arrêtera pas parce des gens me disent ceci ou
cela. Moi je crois que je peux réaliser un algo incassable et je fonce.
Mais chaque étape en son temps. Dans cette étape-ci il y a
plusieurs sous étapes et j'en suis qu'à la 1re. Le fait de savoir si
on peut ou non trouver le clair à partir du chiffré et l'algo, mais
sans faire de force brute ou essayer des clefs différentes jusqu'à
trouver le clair qui correspond au chiffré.
J'ai déjà dis que je ne m'arrêtera pas parce des gens me disent ceci ou
cela. Moi je crois que je peux réaliser un algo incassable et je fonce.
Mais chaque étape en son temps. Dans cette étape-ci il y a
plusieurs sous étapes et j'en suis qu'à la 1re. Le fait de savoir si
on peut ou non trouver le clair à partir du chiffré et l'algo, mais
sans faire de force brute ou essayer des clefs différentes jusqu'à
trouver le clair qui correspond au chiffré.
J'ai déjà dis que je ne m'arrêtera pas parce des gens me disent ceci
ou cela. Moi je crois que je peux réaliser un algo incassable et je
fonce.
Ca-y-est, une phrase mytique :-)
J'ai déjà dis que je ne m'arrêtera pas parce des gens me disent ceci
ou cela. Moi je crois que je peux réaliser un algo incassable et je
fonce.
Ca-y-est, une phrase mytique :-)
J'ai déjà dis que je ne m'arrêtera pas parce des gens me disent ceci
ou cela. Moi je crois que je peux réaliser un algo incassable et je
fonce.
Ca-y-est, une phrase mytique :-)
En fait, le seul incassable est l'OTP modulo les conditions liées aux
clés. Tous les autres sont cassables. Cependant, le grand jeu est de
rendre l'opération aussi difficile que possible. Je conjecture que si
d'autres n'y sont pas arrivés, toi non plus.
Mais chaque étape en son temps. Dans cette étape-ci il y a
plusieurs sous étapes et j'en suis qu'à la 1re. Le fait de savoir si
on peut ou non trouver le clair à partir du chiffré et l'algo, mais
sans faire de force brute ou essayer des clefs différentes jusqu'à
trouver le clair qui correspond au chiffré.
J'ai déjà répondu que la cause était entendue : c'est impossible.
Même en essayant toutes les clés, il n'y aurait pas de possibilités de
savoir si on tombe sur le bon clair. Ton procédé hérite des
propriétés du xor.
Attache-toi à rendre l'attaque à clair connu inopérante.
La
vulnérabilité à cette attaque empêche toute communication de la clé
à plusieurs correspondants,
ce qui est relativement tracassant pour un
algorithme symétrique.
En fait, le seul incassable est l'OTP modulo les conditions liées aux
clés. Tous les autres sont cassables. Cependant, le grand jeu est de
rendre l'opération aussi difficile que possible. Je conjecture que si
d'autres n'y sont pas arrivés, toi non plus.
Mais chaque étape en son temps. Dans cette étape-ci il y a
plusieurs sous étapes et j'en suis qu'à la 1re. Le fait de savoir si
on peut ou non trouver le clair à partir du chiffré et l'algo, mais
sans faire de force brute ou essayer des clefs différentes jusqu'à
trouver le clair qui correspond au chiffré.
J'ai déjà répondu que la cause était entendue : c'est impossible.
Même en essayant toutes les clés, il n'y aurait pas de possibilités de
savoir si on tombe sur le bon clair. Ton procédé hérite des
propriétés du xor.
Attache-toi à rendre l'attaque à clair connu inopérante.
La
vulnérabilité à cette attaque empêche toute communication de la clé
à plusieurs correspondants,
ce qui est relativement tracassant pour un
algorithme symétrique.
En fait, le seul incassable est l'OTP modulo les conditions liées aux
clés. Tous les autres sont cassables. Cependant, le grand jeu est de
rendre l'opération aussi difficile que possible. Je conjecture que si
d'autres n'y sont pas arrivés, toi non plus.
Mais chaque étape en son temps. Dans cette étape-ci il y a
plusieurs sous étapes et j'en suis qu'à la 1re. Le fait de savoir si
on peut ou non trouver le clair à partir du chiffré et l'algo, mais
sans faire de force brute ou essayer des clefs différentes jusqu'à
trouver le clair qui correspond au chiffré.
J'ai déjà répondu que la cause était entendue : c'est impossible.
Même en essayant toutes les clés, il n'y aurait pas de possibilités de
savoir si on tombe sur le bon clair. Ton procédé hérite des
propriétés du xor.
Attache-toi à rendre l'attaque à clair connu inopérante.
La
vulnérabilité à cette attaque empêche toute communication de la clé
à plusieurs correspondants,
ce qui est relativement tracassant pour un
algorithme symétrique.
"Le fait de savoir si on peut ou non 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é."
Je sais que j'ai posé la question ailleurs. Mais je ne suis toujours
pas certain de la réponse à cause de la façon qui a été répondu.
La vulnérabilité à cette attaque empêche toute communication de la
clé à plusieurs correspondants,
Quand vous dites "à plusieurs correspondants", est-ce que vous
parlez de clef public/privé ou de clef privé comme dans le simple
algo ?
"Le fait de savoir si on peut ou non 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é."
Je sais que j'ai posé la question ailleurs. Mais je ne suis toujours
pas certain de la réponse à cause de la façon qui a été répondu.
La vulnérabilité à cette attaque empêche toute communication de la
clé à plusieurs correspondants,
Quand vous dites "à plusieurs correspondants", est-ce que vous
parlez de clef public/privé ou de clef privé comme dans le simple
algo ?
"Le fait de savoir si on peut ou non 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é."
Je sais que j'ai posé la question ailleurs. Mais je ne suis toujours
pas certain de la réponse à cause de la façon qui a été répondu.
La vulnérabilité à cette attaque empêche toute communication de la
clé à plusieurs correspondants,
Quand vous dites "à plusieurs correspondants", est-ce que vous
parlez de clef public/privé ou de clef privé comme dans le simple
algo ?
"Le fait de savoir si on peut ou non 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é."
Je sais que j'ai posé la question ailleurs. Mais je ne suis toujours
pas certain de la réponse à cause de la façon qui a été répondu.
Peu importe les tests réalisés dans un tel programme. En fait,
la question est : pourquoi faut-il éviter la force brute ?
Parce qu'une
telle attaque devient inopérante si la clé est agrandie. Or, le but
c'est bien de pouvoir casser des clés de longueur respectable.
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é.
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é.
$ time ./sax
Clair :
{1,78,255,1,78,251,178,235,148,0,0,7,45,21,111,110,101,17,19,88,37,38,39,40,41,42,45,78,79,99,215,214,213,212,210,207,200,200,188,197,2,2,5,6,7,8,9,56,22,23,24,25,26,27,28,29,30,1,96,97,98,99,100,207,23,24,25,29,67,68,75,76,77,78,95,45,44,43,34,255,255,255,254,253,174,175,176,178,179,180,0,1,2,3,4,5,6,16,17,18}
Chiffré :
{4,32,0,4,32,8,136,40,80,0,0,16,164,84,32,32,20,68,72,64,148,144,144,160,164,168,164,32,32,8,80,80,84,80,72,32,32,32,128,20,8,8,20,16,16,32,36,128,80,80,64,68,72,72,64,68,64,4,0,4,8,8,16,32,80,64,68,68,8,16,40,32,36,32,64,164,160,168,136,0,0,0,0,4,160,160,128,136,136,144,0,4,8,8,16,20,16,64,68,72}
Clé trouvée :
{1,78,255,1,78,251,178,235,148,0,0,7,45,21,111,110,101,17,19,88,37,38,39,40,41,42,45,78,79,99,215,214,213,212,210,207,200,200,188,197,2,2,5,6,7,8,9,56,22,23,24,25,26,27,28,29,30,1,96,97,98,99,100,207,23,24,25,29,67,68,75,76,77,78,95,45,44,43,34,255,255,255,254,253,174,175,176,178,179,180,0,1,2,3,4,5,6,16,17,18}
nbCles : 1
Nombre d'appels total : 25957
Nombre d'appels pour trouver la première clé : 8675
real 0m0.026s
user 0m0.019s
sys 0m0.006s
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.
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.
"Le fait de savoir si on peut ou non 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é."
Je sais que j'ai posé la question ailleurs. Mais je ne suis toujours
pas certain de la réponse à cause de la façon qui a été répondu.
Peu importe les tests réalisés dans un tel programme. En fait,
la question est : pourquoi faut-il éviter la force brute ?
Parce qu'une
telle attaque devient inopérante si la clé est agrandie. Or, le but
c'est bien de pouvoir casser des clés de longueur respectable.
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é.
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é.
$ time ./sax
Clair :
{1,78,255,1,78,251,178,235,148,0,0,7,45,21,111,110,101,17,19,88,37,38,39,40,41,42,45,78,79,99,215,214,213,212,210,207,200,200,188,197,2,2,5,6,7,8,9,56,22,23,24,25,26,27,28,29,30,1,96,97,98,99,100,207,23,24,25,29,67,68,75,76,77,78,95,45,44,43,34,255,255,255,254,253,174,175,176,178,179,180,0,1,2,3,4,5,6,16,17,18}
Chiffré :
{4,32,0,4,32,8,136,40,80,0,0,16,164,84,32,32,20,68,72,64,148,144,144,160,164,168,164,32,32,8,80,80,84,80,72,32,32,32,128,20,8,8,20,16,16,32,36,128,80,80,64,68,72,72,64,68,64,4,0,4,8,8,16,32,80,64,68,68,8,16,40,32,36,32,64,164,160,168,136,0,0,0,0,4,160,160,128,136,136,144,0,4,8,8,16,20,16,64,68,72}
Clé trouvée :
{1,78,255,1,78,251,178,235,148,0,0,7,45,21,111,110,101,17,19,88,37,38,39,40,41,42,45,78,79,99,215,214,213,212,210,207,200,200,188,197,2,2,5,6,7,8,9,56,22,23,24,25,26,27,28,29,30,1,96,97,98,99,100,207,23,24,25,29,67,68,75,76,77,78,95,45,44,43,34,255,255,255,254,253,174,175,176,178,179,180,0,1,2,3,4,5,6,16,17,18}
nbCles : 1
Nombre d'appels total : 25957
Nombre d'appels pour trouver la première clé : 8675
real 0m0.026s
user 0m0.019s
sys 0m0.006s
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.
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.
"Le fait de savoir si on peut ou non 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é."
Je sais que j'ai posé la question ailleurs. Mais je ne suis toujours
pas certain de la réponse à cause de la façon qui a été répondu.
Peu importe les tests réalisés dans un tel programme. En fait,
la question est : pourquoi faut-il éviter la force brute ?
Parce qu'une
telle attaque devient inopérante si la clé est agrandie. Or, le but
c'est bien de pouvoir casser des clés de longueur respectable.
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é.
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é.
$ time ./sax
Clair :
{1,78,255,1,78,251,178,235,148,0,0,7,45,21,111,110,101,17,19,88,37,38,39,40,41,42,45,78,79,99,215,214,213,212,210,207,200,200,188,197,2,2,5,6,7,8,9,56,22,23,24,25,26,27,28,29,30,1,96,97,98,99,100,207,23,24,25,29,67,68,75,76,77,78,95,45,44,43,34,255,255,255,254,253,174,175,176,178,179,180,0,1,2,3,4,5,6,16,17,18}
Chiffré :
{4,32,0,4,32,8,136,40,80,0,0,16,164,84,32,32,20,68,72,64,148,144,144,160,164,168,164,32,32,8,80,80,84,80,72,32,32,32,128,20,8,8,20,16,16,32,36,128,80,80,64,68,72,72,64,68,64,4,0,4,8,8,16,32,80,64,68,68,8,16,40,32,36,32,64,164,160,168,136,0,0,0,0,4,160,160,128,136,136,144,0,4,8,8,16,20,16,64,68,72}
Clé trouvée :
{1,78,255,1,78,251,178,235,148,0,0,7,45,21,111,110,101,17,19,88,37,38,39,40,41,42,45,78,79,99,215,214,213,212,210,207,200,200,188,197,2,2,5,6,7,8,9,56,22,23,24,25,26,27,28,29,30,1,96,97,98,99,100,207,23,24,25,29,67,68,75,76,77,78,95,45,44,43,34,255,255,255,254,253,174,175,176,178,179,180,0,1,2,3,4,5,6,16,17,18}
nbCles : 1
Nombre d'appels total : 25957
Nombre d'appels pour trouver la première clé : 8675
real 0m0.026s
user 0m0.019s
sys 0m0.006s
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.
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.
