AMcD® : méthode de cryptage.

Cedric Blancher

09/12/2004 à 21:25

Le Thu, 09 Dec 2004 15:02:21 -0500, Raymond H. a écrit :
[cmd.exe]

Mais faut reconnaître que la fenêtre que le soft utilise est une fenêtre
DOS.

Ça me fait penser aux gens qui ne comprennent pas comment j'arrive à
travailler sous Linux en préférant la "fenêtre DOS" à l'explorateur de
fichiers...

--
Le message sur le NG c'étais pour tenir informé de l'avancement du
site!Si g voulu en tenir informé le monde C parce que je pensais que
vous étiez interressés par le site et que vous aviez hâte qu'il sorte!
-+- Pip99 in http://www.petitjoueur.net/ : nzn.fr.jeux.pip99 -+-

AMcD®

09/12/2004 à 21:37

Raymond H. wrote:

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour
tenter de décrypter certaines clefs

Non, tu ne comprends pas. Tu n'as rien compris à ce que j'ai montré. Ou,
peut-être, tu ne veux pas comprendre.

Je n'ai pas tenté, j'ai réussi. Dans le domaine de la nuance, cela fait une
différence :-).

même si son soft est limité.

Mon soft n'est pas limité car ce n'est pas un soft. C'est une preuve de
faisabilité. Je n'avais pas le temps d'écrire un truc exhaustif. Je me suis
donc contenté d'un exemple. Et cela suffit, car même il n'y aurait qu'une
faille, c'est déjà de trop.

Mais je vois que tu es têtu... Alors, si cela peut te rassurer, toujours sur
{a,z}, je peux maintenant te casser n'importe clé de 32 à 1024 bits. Tu as
bien lu ? N'importe laquelle de 32 à 1024. Veux-tu encore me tester une
nouvelle fois ?

Il
a un zèle pour ce genre de chose et ca aide à prendre conscience de
certaines choses.

Je n'ai aucun zèle pour cela. J'ai arrêté de m'intéresser à la crypto il y a
bien longtemps, depuis le RSA, les clés asymétriques, etc. Mon truc c'est
les virus et le hacking, tu vois c'est loin de la crypto. Ce que je t'ai
montré n'a rien à voir avec la crypto.

Et en plus j'avais déjà expliqué cela dans un autre message
concernant le temps d'exécution d'une procédure ne faisant des
calculs que pour une clef ayant un minimum de caractères et en
minuscule de a à z. On pourrait comparer par ce moyen les clefs d'à
peu près n'importe lequel des softs de cryptage en autant qu'on ait
quelques calculs pour le faire.

Tu ne comprends toujours pas, tu n'as rien compris à mon exposé, son but.
J'ai choisi {a,z} pour diverses raisons :

- Pour rédiger un texte, c'est plus facile d'utiliser {a,z} et de, par
exemple, de dire soit la clé "biniou" que soit la clé #@^$¨` ;
- Comme tu utilises des décalages de 2 bits (des multiplications par 4), il
y a évidemment des problèmes avec les modulos. Par exemple, lors de la
détermination des octets de chaque caractère de la clé, on a des
multiplications par 3, par 4, etc. Donc, si je prends le cas de 4, sur
l'ensemble des 256 caractères ASCII étendus, il y aura 4 groupes de 64
caratères (256/4) qui possèderont des octets égaux (enfin, certains), on
appelle ça des collisions. Dans ton cas, c'est facile à gérér puisqu'il me
suffirait de faire une table pour les 256 caractères et de comparer le
deuxième, troisième, etc. octet chiffré de chaque clé. Mais, comme déjà
expliqué, j'ai autre chose à faire. Mais, si tu veux, au lieu de prendre
{a,z}, mon exemple marche très bien sur {A,Z}u{[]^^_`}u{a,z} par exemple.
Il suffit d'utiliser un sous-ensemble de 64 caractères. Bref, l'ensemble
'{a,z} n'a rien à voir avec ma méthode. Comment ne comrpends-tu pas ça ?

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé !
J'utilise une formule, une simple formule.

J'ose espérer que vous y connaissiez
quelque chose et que vous parlez pas seulement d'après ce que
d'autres vous disent! Cela peut prendre d'une fraction de seconde à
quelques secondes pour trouver ces quelques clefs via un soft créé à
cet effet avec une limitation de quelques caractères seulement. Il
y a quand même une différence avec une clef de 1024 qui ne se limite
pas à des minuscule de a à z.

Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z} je te dis !!!
C'est pas possible une mule pareille. Et si j'avais le temps, sur tout le
domaine de la table ASCII étendue.

Et comme j'ai dis auparavant, pour
trouver une clef dans AllCrypter il faut, en plus des calculs, faire
des comparaisons dans une boucle pour trouver une clef dans
AllCrypter sinon c'est impossible sans la clef (en clair) elle-même.

Franchement, tu es de plus en plus ridicule.

On pourrait faire ainsi avec presque n'importe lequel
des logiciels de cryptage en autant de posséder suffisamment de
calculs pour le faire.

Il y a 1 (UN) calcul à faire, j'applique une formule ! Tu vas comprendre à
un moment donné ?

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

mais y intégrer, si
désiré, un code qui l'identifie plutôt,

Si tu ne changes pas la formule de calcul de la clé, ça changera quoi ?

C'est une leçon à en tirer.

Comment veux-tu tirer des leçons ? Tu ne comprends que ce que tu veux
comprendre et détourne jusqu'à ce que ça t'arrange !

Mais comme j'ai
dit, il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! T'es vraiment bouché mon pauvre ami. Et si tu
crois que beaucoup de gens dépassent 12 caractères pour leurs clés, tu te
fais une très mauvaise idée de tes clients...

Mais bon! On doit avancer et se perfectionner dans nos algos si cela
est nécessaire (je parle pour moi-même).

Oh mais il était bien avancé mon programme ! Tiens, je suis bon prince,
voici la partie qui calcule (en affichant le détail !!!) les octets de
n'importe quelle clé multiple de 16 bits de AllCrypter, de 32 à 128 bits :

#define NK 6

int weak_index[16][17] = {
0,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 8 bits
1, 1,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 16 bits
2, 1, 2,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 24 bits
3, 2, 1, 3,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 32 bits
4, 2, 3, 1, 4,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 40 bits
5, 3, 2, 4, 1, 5,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 48 bits
6, 3, 4, 2, 5, 1, 6,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 56 bits
7, 4, 3, 5, 2, 6, 1, 7,
0,-1,-1,-1,-1,-1,-1,-1,-1, // 64 bits
8, 4, 5, 3, 6, 2, 7, 1, 8,
0,-1,-1,-1,-1,-1,-1,-1, // 72 bits
9, 5, 4, 6, 3, 7, 2, 8, 1, 9,
0,-1,-1,-1,-1,-1,-1, // 80 bits
10, 5, 6, 4, 7, 3, 8, 2, 9, 1,10,
0,-1,-1,-1,-1,-1, // 88 bits
11, 6, 5, 7, 4, 8, 3, 9, 2,10, 1,11,
0,-1,-1,-1,-1, // 96 bits
12, 6, 7, 5, 8, 4, 9, 3,10, 2,11, 1,12,
0,-1,-1,-1, // 104 bits
13, 7, 6, 8, 5, 9, 4,10, 3,11, 2,12, 1,13,
0,-1,-1, // 112 bits
14, 7, 8, 6, 9, 5,10, 4,11, 3,12, 2,13, 1,14,
0,-1, // 120 bits
15, 8, 7, 9, 6,10, 5,11, 4,12, 3,13, 2,14, 1,15,
0 // 128 bits
};
int i[NK] = { -1 };
int A[NK][4] = { -1 };
int z[2*NK] = { 0 };
int index0,index1,index2,index3 = 0;
int a,b,c,d;
int ASCIIStart = 97;
int c1 = 0x83;
int c2 = 0x40;

char keyToFind[] = "E9E0C1C6D1D3D5D4CDDAFD";

char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int j;

for ( j = 0; j < 2*NK; j++ ) org[j] = 129 + j*2;

for ( j = 0; j < 2*NK; j++ )
{
a = keyToFind[j*2];

b = keyToFind[j*2+1];

if ( a > 64 ) a -= 55;

if ( a > 47 ) a -= 48;

if ( b > 64 ) b -= 55;

if ( b > 47 ) b -= 48;

z[j] = a * 16 + b;
}

// in à i1

for ( j = 0; j < NK-1; j++ )
{
index0 = weak_index[NK-1][1+j];

// Premier

if ( j == 0 )
{
index1 = 1;

A[index0][index1] = z[ weak_index[NK-1][0] ];

i[index0] = ( A[index0][index1] - (c1+NK*2) ) / 4 + ASCIIStart;

index1 = 0;

index2 = NK-2;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 2;

index3 = index2 + 2;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
else
{
index0 = weak_index[NK-1][1+j];

index1 = 1;

A[index0][index1] = z[c] + org[c] - a;

i[index0] = ( A[index0][index1] - (c2+NK*2-2*j) ) / 3 + ASCIIStart;

index1 = 2;

A[index0][index1] = z[d] + org[d] - b;

index1 = 0;

index2 = c - 1;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 3;

index3 = d + 1;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
}

À la fin de ce code, tu as les octets i1-i2N-1 (dans la table i[]) de la clé
dont les octets figurent dans keyToFind[]. Le dernier octet à calculer (le
premier de la clé), i0, il suffit de brute-forcer sur {a,z} en calculant les
octets de la clé, K0 à K(2NK-1) et de comparer à keyToFind[]. Je n'ai pas
mis tout le code hein. Et c'est un peu plus complexe que les autres
exemples, c'est sûr...

Compare avec le code du 80 bits et tu comprendras vite ce qui se passe :-).

Étudie bien le code, tu verras qu'il suffit de jouer sur quelques constantes
pour agrandir {a,z} ou le nombre de bits de la clé à craquer.

Pour en faire une version exhaustive, il suffirait de boucler de NK = 4 (32
bits) à NK = 128 (1024 bits) et de régler les constantes c1 et c2 pour
prendre en compte les collisions dues aux multiplications par 3 et 4, on
pourrait ainsi, EN MOINS D'UNE SECONDE, trouver n'importe quelle clé.

Pour ta gouverne, il me faudrait une grosse après-midi (allez, une journée)
pour faire cela et écrire un code plus pro.

Mais, pour ma part, j'en reste là. Tu es de mauvaise foi, le coup du texte
"*Lzpacfiik", c'est assez petit.

L'amélioration de ton soft ne passera plus par moi.

Voilà. J'en ai terminé de flooder ce NG avec cette affaire. Remarque, ça
aura mis un peu d'ambiance :-).

Bien cordialement, mais avec rancune (Becoz *Lzpacfiik...).

--
AMcD®

http://arnold.mcdonald.free.fr/

Raymond H. wrote:

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour
tenter de décrypter certaines clefs

Non, tu ne comprends pas. Tu n'as rien compris à ce que j'ai montré. Ou,
peut-être, tu ne veux pas comprendre.

Je n'ai pas tenté, j'ai réussi. Dans le domaine de la nuance, cela fait une
différence :-).

même si son soft est limité.

Mon soft n'est pas limité car ce n'est pas un soft. C'est une preuve de
faisabilité. Je n'avais pas le temps d'écrire un truc exhaustif. Je me suis
donc contenté d'un exemple. Et cela suffit, car même il n'y aurait qu'une
faille, c'est déjà de trop.

Mais je vois que tu es têtu... Alors, si cela peut te rassurer, toujours sur
{a,z}, je peux maintenant te casser n'importe clé de 32 à 1024 bits. Tu as
bien lu ? N'importe laquelle de 32 à 1024. Veux-tu encore me tester une
nouvelle fois ?

Il
a un zèle pour ce genre de chose et ca aide à prendre conscience de
certaines choses.

Je n'ai aucun zèle pour cela. J'ai arrêté de m'intéresser à la crypto il y a
bien longtemps, depuis le RSA, les clés asymétriques, etc. Mon truc c'est
les virus et le hacking, tu vois c'est loin de la crypto. Ce que je t'ai
montré n'a rien à voir avec la crypto.

Et en plus j'avais déjà expliqué cela dans un autre message
concernant le temps d'exécution d'une procédure ne faisant des
calculs que pour une clef ayant un minimum de caractères et en
minuscule de a à z. On pourrait comparer par ce moyen les clefs d'à
peu près n'importe lequel des softs de cryptage en autant qu'on ait
quelques calculs pour le faire.

Tu ne comprends toujours pas, tu n'as rien compris à mon exposé, son but.
J'ai choisi {a,z} pour diverses raisons :

- Pour rédiger un texte, c'est plus facile d'utiliser {a,z} et de, par
exemple, de dire soit la clé "biniou" que soit la clé #@^$¨` ;
- Comme tu utilises des décalages de 2 bits (des multiplications par 4), il
y a évidemment des problèmes avec les modulos. Par exemple, lors de la
détermination des octets de chaque caractère de la clé, on a des
multiplications par 3, par 4, etc. Donc, si je prends le cas de 4, sur
l'ensemble des 256 caractères ASCII étendus, il y aura 4 groupes de 64
caratères (256/4) qui possèderont des octets égaux (enfin, certains), on
appelle ça des collisions. Dans ton cas, c'est facile à gérér puisqu'il me
suffirait de faire une table pour les 256 caractères et de comparer le
deuxième, troisième, etc. octet chiffré de chaque clé. Mais, comme déjà
expliqué, j'ai autre chose à faire. Mais, si tu veux, au lieu de prendre
{a,z}, mon exemple marche très bien sur {A,Z}u{[]^^_`}u{a,z} par exemple.
Il suffit d'utiliser un sous-ensemble de 64 caractères. Bref, l'ensemble
'{a,z} n'a rien à voir avec ma méthode. Comment ne comrpends-tu pas ça ?

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé !
J'utilise une formule, une simple formule.

J'ose espérer que vous y connaissiez
quelque chose et que vous parlez pas seulement d'après ce que
d'autres vous disent! Cela peut prendre d'une fraction de seconde à
quelques secondes pour trouver ces quelques clefs via un soft créé à
cet effet avec une limitation de quelques caractères seulement. Il
y a quand même une différence avec une clef de 1024 qui ne se limite
pas à des minuscule de a à z.

Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z} je te dis !!!
C'est pas possible une mule pareille. Et si j'avais le temps, sur tout le
domaine de la table ASCII étendue.

Et comme j'ai dis auparavant, pour
trouver une clef dans AllCrypter il faut, en plus des calculs, faire
des comparaisons dans une boucle pour trouver une clef dans
AllCrypter sinon c'est impossible sans la clef (en clair) elle-même.

Franchement, tu es de plus en plus ridicule.

On pourrait faire ainsi avec presque n'importe lequel
des logiciels de cryptage en autant de posséder suffisamment de
calculs pour le faire.

Il y a 1 (UN) calcul à faire, j'applique une formule ! Tu vas comprendre à
un moment donné ?

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

mais y intégrer, si
désiré, un code qui l'identifie plutôt,

Si tu ne changes pas la formule de calcul de la clé, ça changera quoi ?

C'est une leçon à en tirer.

Comment veux-tu tirer des leçons ? Tu ne comprends que ce que tu veux
comprendre et détourne jusqu'à ce que ça t'arrange !

Mais comme j'ai
dit, il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! T'es vraiment bouché mon pauvre ami. Et si tu
crois que beaucoup de gens dépassent 12 caractères pour leurs clés, tu te
fais une très mauvaise idée de tes clients...

Mais bon! On doit avancer et se perfectionner dans nos algos si cela
est nécessaire (je parle pour moi-même).

Oh mais il était bien avancé mon programme ! Tiens, je suis bon prince,
voici la partie qui calcule (en affichant le détail !!!) les octets de
n'importe quelle clé multiple de 16 bits de AllCrypter, de 32 à 128 bits :

#define NK 6

int weak_index[16][17] = {
0,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 8 bits
1, 1,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 16 bits
2, 1, 2,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 24 bits
3, 2, 1, 3,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 32 bits
4, 2, 3, 1, 4,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 40 bits
5, 3, 2, 4, 1, 5,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 48 bits
6, 3, 4, 2, 5, 1, 6,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 56 bits
7, 4, 3, 5, 2, 6, 1, 7,
0,-1,-1,-1,-1,-1,-1,-1,-1, // 64 bits
8, 4, 5, 3, 6, 2, 7, 1, 8,
0,-1,-1,-1,-1,-1,-1,-1, // 72 bits
9, 5, 4, 6, 3, 7, 2, 8, 1, 9,
0,-1,-1,-1,-1,-1,-1, // 80 bits
10, 5, 6, 4, 7, 3, 8, 2, 9, 1,10,
0,-1,-1,-1,-1,-1, // 88 bits
11, 6, 5, 7, 4, 8, 3, 9, 2,10, 1,11,
0,-1,-1,-1,-1, // 96 bits
12, 6, 7, 5, 8, 4, 9, 3,10, 2,11, 1,12,
0,-1,-1,-1, // 104 bits
13, 7, 6, 8, 5, 9, 4,10, 3,11, 2,12, 1,13,
0,-1,-1, // 112 bits
14, 7, 8, 6, 9, 5,10, 4,11, 3,12, 2,13, 1,14,
0,-1, // 120 bits
15, 8, 7, 9, 6,10, 5,11, 4,12, 3,13, 2,14, 1,15,
0 // 128 bits
};
int i[NK] = { -1 };
int A[NK][4] = { -1 };
int z[2*NK] = { 0 };
int index0,index1,index2,index3 = 0;
int a,b,c,d;
int ASCIIStart = 97;
int c1 = 0x83;
int c2 = 0x40;

char keyToFind[] = "E9E0C1C6D1D3D5D4CDDAFD";

char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int j;

for ( j = 0; j < 2*NK; j++ ) org[j] = 129 + j*2;

for ( j = 0; j < 2*NK; j++ )
{
a = keyToFind[j*2];

b = keyToFind[j*2+1];

if ( a > 64 ) a -= 55;

if ( a > 47 ) a -= 48;

if ( b > 64 ) b -= 55;

if ( b > 47 ) b -= 48;

z[j] = a * 16 + b;
}

// in à i1

for ( j = 0; j < NK-1; j++ )
{
index0 = weak_index[NK-1][1+j];

// Premier

if ( j == 0 )
{
index1 = 1;

A[index0][index1] = z[ weak_index[NK-1][0] ];

i[index0] = ( A[index0][index1] - (c1+NK*2) ) / 4 + ASCIIStart;

index1 = 0;

index2 = NK-2;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 2;

index3 = index2 + 2;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
else
{
index0 = weak_index[NK-1][1+j];

index1 = 1;

A[index0][index1] = z[c] + org[c] - a;

i[index0] = ( A[index0][index1] - (c2+NK*2-2*j) ) / 3 + ASCIIStart;

index1 = 2;

A[index0][index1] = z[d] + org[d] - b;

index1 = 0;

index2 = c - 1;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 3;

index3 = d + 1;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
}

À la fin de ce code, tu as les octets i1-i2N-1 (dans la table i[]) de la clé
dont les octets figurent dans keyToFind[]. Le dernier octet à calculer (le
premier de la clé), i0, il suffit de brute-forcer sur {a,z} en calculant les
octets de la clé, K0 à K(2NK-1) et de comparer à keyToFind[]. Je n'ai pas
mis tout le code hein. Et c'est un peu plus complexe que les autres
exemples, c'est sûr...

Compare avec le code du 80 bits et tu comprendras vite ce qui se passe :-).

Étudie bien le code, tu verras qu'il suffit de jouer sur quelques constantes
pour agrandir {a,z} ou le nombre de bits de la clé à craquer.

Pour en faire une version exhaustive, il suffirait de boucler de NK = 4 (32
bits) à NK = 128 (1024 bits) et de régler les constantes c1 et c2 pour
prendre en compte les collisions dues aux multiplications par 3 et 4, on
pourrait ainsi, EN MOINS D'UNE SECONDE, trouver n'importe quelle clé.

Pour ta gouverne, il me faudrait une grosse après-midi (allez, une journée)
pour faire cela et écrire un code plus pro.

Mais, pour ma part, j'en reste là. Tu es de mauvaise foi, le coup du texte
"*Lzpacfiik", c'est assez petit.

L'amélioration de ton soft ne passera plus par moi.

Voilà. J'en ai terminé de flooder ce NG avec cette affaire. Remarque, ça
aura mis un peu d'ambiance :-).

Bien cordialement, mais avec rancune (Becoz *Lzpacfiik...).

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Raymond H. wrote:

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour
tenter de décrypter certaines clefs

Non, tu ne comprends pas. Tu n'as rien compris à ce que j'ai montré. Ou,
peut-être, tu ne veux pas comprendre.

Je n'ai pas tenté, j'ai réussi. Dans le domaine de la nuance, cela fait une
différence :-).

même si son soft est limité.

Mon soft n'est pas limité car ce n'est pas un soft. C'est une preuve de
faisabilité. Je n'avais pas le temps d'écrire un truc exhaustif. Je me suis
donc contenté d'un exemple. Et cela suffit, car même il n'y aurait qu'une
faille, c'est déjà de trop.

Mais je vois que tu es têtu... Alors, si cela peut te rassurer, toujours sur
{a,z}, je peux maintenant te casser n'importe clé de 32 à 1024 bits. Tu as
bien lu ? N'importe laquelle de 32 à 1024. Veux-tu encore me tester une
nouvelle fois ?

Il
a un zèle pour ce genre de chose et ca aide à prendre conscience de
certaines choses.

Je n'ai aucun zèle pour cela. J'ai arrêté de m'intéresser à la crypto il y a
bien longtemps, depuis le RSA, les clés asymétriques, etc. Mon truc c'est
les virus et le hacking, tu vois c'est loin de la crypto. Ce que je t'ai
montré n'a rien à voir avec la crypto.

Et en plus j'avais déjà expliqué cela dans un autre message
concernant le temps d'exécution d'une procédure ne faisant des
calculs que pour une clef ayant un minimum de caractères et en
minuscule de a à z. On pourrait comparer par ce moyen les clefs d'à
peu près n'importe lequel des softs de cryptage en autant qu'on ait
quelques calculs pour le faire.

Tu ne comprends toujours pas, tu n'as rien compris à mon exposé, son but.
J'ai choisi {a,z} pour diverses raisons :

- Pour rédiger un texte, c'est plus facile d'utiliser {a,z} et de, par
exemple, de dire soit la clé "biniou" que soit la clé #@^$¨` ;
- Comme tu utilises des décalages de 2 bits (des multiplications par 4), il
y a évidemment des problèmes avec les modulos. Par exemple, lors de la
détermination des octets de chaque caractère de la clé, on a des
multiplications par 3, par 4, etc. Donc, si je prends le cas de 4, sur
l'ensemble des 256 caractères ASCII étendus, il y aura 4 groupes de 64
caratères (256/4) qui possèderont des octets égaux (enfin, certains), on
appelle ça des collisions. Dans ton cas, c'est facile à gérér puisqu'il me
suffirait de faire une table pour les 256 caractères et de comparer le
deuxième, troisième, etc. octet chiffré de chaque clé. Mais, comme déjà
expliqué, j'ai autre chose à faire. Mais, si tu veux, au lieu de prendre
{a,z}, mon exemple marche très bien sur {A,Z}u{[]^^_`}u{a,z} par exemple.
Il suffit d'utiliser un sous-ensemble de 64 caractères. Bref, l'ensemble
'{a,z} n'a rien à voir avec ma méthode. Comment ne comrpends-tu pas ça ?

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé !
J'utilise une formule, une simple formule.

J'ose espérer que vous y connaissiez
quelque chose et que vous parlez pas seulement d'après ce que
d'autres vous disent! Cela peut prendre d'une fraction de seconde à
quelques secondes pour trouver ces quelques clefs via un soft créé à
cet effet avec une limitation de quelques caractères seulement. Il
y a quand même une différence avec une clef de 1024 qui ne se limite
pas à des minuscule de a à z.

Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z} je te dis !!!
C'est pas possible une mule pareille. Et si j'avais le temps, sur tout le
domaine de la table ASCII étendue.

Et comme j'ai dis auparavant, pour
trouver une clef dans AllCrypter il faut, en plus des calculs, faire
des comparaisons dans une boucle pour trouver une clef dans
AllCrypter sinon c'est impossible sans la clef (en clair) elle-même.

Franchement, tu es de plus en plus ridicule.

On pourrait faire ainsi avec presque n'importe lequel
des logiciels de cryptage en autant de posséder suffisamment de
calculs pour le faire.

Il y a 1 (UN) calcul à faire, j'applique une formule ! Tu vas comprendre à
un moment donné ?

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

mais y intégrer, si
désiré, un code qui l'identifie plutôt,

Si tu ne changes pas la formule de calcul de la clé, ça changera quoi ?

C'est une leçon à en tirer.

Comment veux-tu tirer des leçons ? Tu ne comprends que ce que tu veux
comprendre et détourne jusqu'à ce que ça t'arrange !

Mais comme j'ai
dit, il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! T'es vraiment bouché mon pauvre ami. Et si tu
crois que beaucoup de gens dépassent 12 caractères pour leurs clés, tu te
fais une très mauvaise idée de tes clients...

Mais bon! On doit avancer et se perfectionner dans nos algos si cela
est nécessaire (je parle pour moi-même).

Oh mais il était bien avancé mon programme ! Tiens, je suis bon prince,
voici la partie qui calcule (en affichant le détail !!!) les octets de
n'importe quelle clé multiple de 16 bits de AllCrypter, de 32 à 128 bits :

#define NK 6

int weak_index[16][17] = {
0,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 8 bits
1, 1,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 16 bits
2, 1, 2,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 24 bits
3, 2, 1, 3,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 32 bits
4, 2, 3, 1, 4,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 40 bits
5, 3, 2, 4, 1, 5,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 48 bits
6, 3, 4, 2, 5, 1, 6,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 56 bits
7, 4, 3, 5, 2, 6, 1, 7,
0,-1,-1,-1,-1,-1,-1,-1,-1, // 64 bits
8, 4, 5, 3, 6, 2, 7, 1, 8,
0,-1,-1,-1,-1,-1,-1,-1, // 72 bits
9, 5, 4, 6, 3, 7, 2, 8, 1, 9,
0,-1,-1,-1,-1,-1,-1, // 80 bits
10, 5, 6, 4, 7, 3, 8, 2, 9, 1,10,
0,-1,-1,-1,-1,-1, // 88 bits
11, 6, 5, 7, 4, 8, 3, 9, 2,10, 1,11,
0,-1,-1,-1,-1, // 96 bits
12, 6, 7, 5, 8, 4, 9, 3,10, 2,11, 1,12,
0,-1,-1,-1, // 104 bits
13, 7, 6, 8, 5, 9, 4,10, 3,11, 2,12, 1,13,
0,-1,-1, // 112 bits
14, 7, 8, 6, 9, 5,10, 4,11, 3,12, 2,13, 1,14,
0,-1, // 120 bits
15, 8, 7, 9, 6,10, 5,11, 4,12, 3,13, 2,14, 1,15,
0 // 128 bits
};
int i[NK] = { -1 };
int A[NK][4] = { -1 };
int z[2*NK] = { 0 };
int index0,index1,index2,index3 = 0;
int a,b,c,d;
int ASCIIStart = 97;
int c1 = 0x83;
int c2 = 0x40;

char keyToFind[] = "E9E0C1C6D1D3D5D4CDDAFD";

char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int j;

for ( j = 0; j < 2*NK; j++ ) org[j] = 129 + j*2;

for ( j = 0; j < 2*NK; j++ )
{
a = keyToFind[j*2];

b = keyToFind[j*2+1];

if ( a > 64 ) a -= 55;

if ( a > 47 ) a -= 48;

if ( b > 64 ) b -= 55;

if ( b > 47 ) b -= 48;

z[j] = a * 16 + b;
}

// in à i1

for ( j = 0; j < NK-1; j++ )
{
index0 = weak_index[NK-1][1+j];

// Premier

if ( j == 0 )
{
index1 = 1;

A[index0][index1] = z[ weak_index[NK-1][0] ];

i[index0] = ( A[index0][index1] - (c1+NK*2) ) / 4 + ASCIIStart;

index1 = 0;

index2 = NK-2;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 2;

index3 = index2 + 2;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
else
{
index0 = weak_index[NK-1][1+j];

index1 = 1;

A[index0][index1] = z[c] + org[c] - a;

i[index0] = ( A[index0][index1] - (c2+NK*2-2*j) ) / 3 + ASCIIStart;

index1 = 2;

A[index0][index1] = z[d] + org[d] - b;

index1 = 0;

index2 = c - 1;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 3;

index3 = d + 1;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
}

À la fin de ce code, tu as les octets i1-i2N-1 (dans la table i[]) de la clé
dont les octets figurent dans keyToFind[]. Le dernier octet à calculer (le
premier de la clé), i0, il suffit de brute-forcer sur {a,z} en calculant les
octets de la clé, K0 à K(2NK-1) et de comparer à keyToFind[]. Je n'ai pas
mis tout le code hein. Et c'est un peu plus complexe que les autres
exemples, c'est sûr...

Compare avec le code du 80 bits et tu comprendras vite ce qui se passe :-).

Étudie bien le code, tu verras qu'il suffit de jouer sur quelques constantes
pour agrandir {a,z} ou le nombre de bits de la clé à craquer.

Pour en faire une version exhaustive, il suffirait de boucler de NK = 4 (32
bits) à NK = 128 (1024 bits) et de régler les constantes c1 et c2 pour
prendre en compte les collisions dues aux multiplications par 3 et 4, on
pourrait ainsi, EN MOINS D'UNE SECONDE, trouver n'importe quelle clé.

Pour ta gouverne, il me faudrait une grosse après-midi (allez, une journée)
pour faire cela et écrire un code plus pro.

Mais, pour ma part, j'en reste là. Tu es de mauvaise foi, le coup du texte
"*Lzpacfiik", c'est assez petit.

L'amélioration de ton soft ne passera plus par moi.

Voilà. J'en ai terminé de flooder ce NG avec cette affaire. Remarque, ça
aura mis un peu d'ambiance :-).

Bien cordialement, mais avec rancune (Becoz *Lzpacfiik...).

--
AMcD®

http://arnold.mcdonald.free.fr/

Raymond H.

09/12/2004 à 23:41

"AMcD®" a écrit dans le message de news:
41b8b78c$0$9842$

Raymond H. wrote:

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour
tenter de décrypter certaines clefs

Non, tu ne comprends pas. Tu n'as rien compris à ce que j'ai montré. Ou,
peut-être, tu ne veux pas comprendre.

Je n'ai pas tenté, j'ai réussi. Dans le domaine de la nuance, cela fait
une différence :-).

Mais vous avez tentez pour pouvoir réussir le bout que vous avez fait.
C'est ce que je veux dire.

même si son soft est limité.

Mon soft n'est pas limité car ce n'est pas un soft.

Mais oui, c'est un soft et 'soft' signifie 'mou', autrement dit ce n'est pas
du Hardware 'dur' mais sur software (logiciel; je parle du exe).

C'est une preuve de faisabilité. Je n'avais pas le temps d'écrire un truc
exhaustif. Je me suis donc contenté d'un exemple. Et cela suffit, car même
il n'y aurait qu'une faille, c'est déjà de trop.

Mais je vois que tu es têtu... Alors, si cela peut te rassurer, toujours
sur {a,z}, je peux maintenant te casser n'importe clé de 32 à 1024 bits.
Tu as bien lu ? N'importe laquelle de 32 à 1024. Veux-tu encore me tester
une nouvelle fois ?

Il
a un zèle pour ce genre de chose et ca aide à prendre conscience de
certaines choses.

Je n'ai aucun zèle pour cela.

Prenez au moins ce mot dans le sens de 'dévouement' selon le Petit
Robert. Mais bon! Si vous aimez mieux me contredire sur presque tout ce que
je dis pour tenter de vous plaire alors je subi.

J'ai arrêté de m'intéresser à la crypto il y a bien longtemps, depuis le
RSA, les clés asymétriques, etc. Mon truc c'est les virus et le hacking,
tu vois c'est loin de la crypto. Ce que je t'ai montré n'a rien à voir
avec la crypto.

Il n'est donc pas question de cryptologie ici? Autre chose pour me
contredire?

Et en plus j'avais déjà expliqué cela dans un autre message
concernant le temps d'exécution d'une procédure ne faisant des
calculs que pour une clef ayant un minimum de caractères et en
minuscule de a à z. On pourrait comparer par ce moyen les clefs d'à
peu près n'importe lequel des softs de cryptage en autant qu'on ait
quelques calculs pour le faire.

Tu ne comprends toujours pas, tu n'as rien compris à mon exposé, son but.
J'ai choisi {a,z} pour diverses raisons :

- Pour rédiger un texte, c'est plus facile d'utiliser {a,z} et de, par
exemple, de dire soit la clé "biniou" que soit la clé #@^$¨` ;
- Comme tu utilises des décalages de 2 bits (des multiplications par 4),
il y a évidemment des problèmes avec les modulos. Par exemple, lors de la
détermination des octets de chaque caractère de la clé, on a des
multiplications par 3, par 4, etc. Donc, si je prends le cas de 4, sur
l'ensemble des 256 caractères ASCII étendus, il y aura 4 groupes de 64
caratères (256/4) qui possèderont des octets égaux (enfin, certains), on
appelle ça des collisions. Dans ton cas, c'est facile à gérér puisqu'il me
suffirait de faire une table pour les 256 caractères et de comparer le
deuxième, troisième, etc. octet chiffré de chaque clé. Mais, comme déjà
expliqué, j'ai autre chose à faire. Mais, si tu veux, au lieu de prendre
{a,z}, mon exemple marche très bien sur {A,Z}u{[]^^_`}u{a,z} par exemple.
Il suffit d'utiliser un sous-ensemble de 64 caractères. Bref, l'ensemble
'{a,z} n'a rien à voir avec ma méthode. Comment ne comrpends-tu pas ça ?

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé
!

Ce n'est pas ce que je veux dire. Je parle de certains caractères ou
données pour la comparaison avec le chiffré pour compléter.

J'utilise une formule, une simple formule.

J'ose espérer que vous y connaissiez
quelque chose et que vous parlez pas seulement d'après ce que
d'autres vous disent! Cela peut prendre d'une fraction de seconde à
quelques secondes pour trouver ces quelques clefs via un soft créé à
cet effet avec une limitation de quelques caractères seulement. Il
y a quand même une différence avec une clef de 1024 qui ne se limite
pas à des minuscule de a à z.

Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z} je te dis
!!! C'est pas possible une mule pareille. Et si j'avais le temps, sur tout
le domaine de la table ASCII étendue.

Bon bien tant mieux pour vous et tant pis pour moi :)
Cela me montre de ne pas intégrer une clef dans le chiffré.
Pas de problème là dessus.

Et comme j'ai dis auparavant, pour
trouver une clef dans AllCrypter il faut, en plus des calculs, faire
des comparaisons dans une boucle pour trouver une clef dans
AllCrypter sinon c'est impossible sans la clef (en clair) elle-même.

Franchement, tu es de plus en plus ridicule.

On pourrait faire ainsi avec presque n'importe lequel
des logiciels de cryptage en autant de posséder suffisamment de
calculs pour le faire.

Il y a 1 (UN) calcul à faire, j'applique une formule ! Tu vas comprendre à
un moment donné ?

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

Merci du conseil.

mais y intégrer, si
désiré, un code qui l'identifie plutôt,

Si tu ne changes pas la formule de calcul de la clé, ça changera quoi ?

En effet je travaille déjà à la modifier, et c'est pourquoi le reste aussi
sera modifié puisque ca fonctionne ensemble.

C'est une leçon à en tirer.

Comment veux-tu tirer des leçons ? Tu ne comprends que ce que tu veux
comprendre et détourne jusqu'à ce que ça t'arrange !

Je parle humblement de tirer une leçon (du moins dans ce que je réalise)
mais encore une contradiction.

Mais comme j'ai
dit, il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! T'es vraiment bouché mon pauvre ami. Et si tu
crois que beaucoup de gens dépassent 12 caractères pour leurs clés, tu te
fais une très mauvaise idée de tes clients...

Mais bon! On doit avancer et se perfectionner dans nos algos si cela
est nécessaire (je parle pour moi-même).

Oh mais il était bien avancé mon programme ! Tiens, je suis bon prince,
voici la partie qui calcule (en affichant le détail !!!) les octets de
n'importe quelle clé multiple de 16 bits de AllCrypter, de 32 à 128 bits :

#define NK 6

int weak_index[16][17] = {
0,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 8 bits
1, 1,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 16 bits
2, 1, 2,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 24 bits
3, 2, 1, 3,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 32 bits
4, 2, 3, 1, 4,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 40 bits
5, 3, 2, 4, 1, 5,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 48 bits
6, 3, 4, 2, 5, 1, 6,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 56 bits
7, 4, 3, 5, 2, 6, 1, 7,
0,-1,-1,-1,-1,-1,-1,-1,-1, // 64 bits
8, 4, 5, 3, 6, 2, 7, 1, 8,
0,-1,-1,-1,-1,-1,-1,-1, // 72 bits
9, 5, 4, 6, 3, 7, 2, 8, 1, 9,
0,-1,-1,-1,-1,-1,-1, // 80 bits
10, 5, 6, 4, 7, 3, 8, 2, 9, 1,10,
0,-1,-1,-1,-1,-1, // 88 bits
11, 6, 5, 7, 4, 8, 3, 9, 2,10, 1,11,
0,-1,-1,-1,-1, // 96 bits
12, 6, 7, 5, 8, 4, 9, 3,10, 2,11, 1,12,
0,-1,-1,-1, // 104 bits
13, 7, 6, 8, 5, 9, 4,10, 3,11, 2,12, 1,13,
0,-1,-1, // 112 bits
14, 7, 8, 6, 9, 5,10, 4,11, 3,12, 2,13, 1,14,
0,-1, // 120 bits
15, 8, 7, 9, 6,10, 5,11, 4,12, 3,13, 2,14, 1,15,
0 // 128 bits
};
int i[NK] = { -1 };
int A[NK][4] = { -1 };
int z[2*NK] = { 0 };
int index0,index1,index2,index3 = 0;
int a,b,c,d;
int ASCIIStart = 97;
int c1 = 0x83;
int c2 = 0x40;

char keyToFind[] = "E9E0C1C6D1D3D5D4CDDAFD";

char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int j;

for ( j = 0; j < 2*NK; j++ ) org[j] = 129 + j*2;

for ( j = 0; j < 2*NK; j++ )
{
a = keyToFind[j*2];

b = keyToFind[j*2+1];

if ( a > 64 ) a -= 55;

if ( a > 47 ) a -= 48;

if ( b > 64 ) b -= 55;

if ( b > 47 ) b -= 48;

z[j] = a * 16 + b;
}

// in à i1

for ( j = 0; j < NK-1; j++ )
{
index0 = weak_index[NK-1][1+j];

// Premier

if ( j == 0 )
{
index1 = 1;

A[index0][index1] = z[ weak_index[NK-1][0] ];

i[index0] = ( A[index0][index1] - (c1+NK*2) ) / 4 + ASCIIStart;

index1 = 0;

index2 = NK-2;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 2;

index3 = index2 + 2;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
else
{
index0 = weak_index[NK-1][1+j];

index1 = 1;

A[index0][index1] = z[c] + org[c] - a;

i[index0] = ( A[index0][index1] - (c2+NK*2-2*j) ) / 3 + ASCIIStart;

index1 = 2;

A[index0][index1] = z[d] + org[d] - b;

index1 = 0;

index2 = c - 1;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 3;

index3 = d + 1;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
}

À la fin de ce code, tu as les octets i1-i2N-1 (dans la table i[]) de la
clé dont les octets figurent dans keyToFind[]. Le dernier octet à calculer
(le premier de la clé), i0, il suffit de brute-forcer sur {a,z} en
calculant les octets de la clé, K0 à K(2NK-1) et de comparer à
keyToFind[]. Je n'ai pas mis tout le code hein. Et c'est un peu plus
complexe que les autres exemples, c'est sûr...

Compare avec le code du 80 bits et tu comprendras vite ce qui se passe
:-).

Étudie bien le code, tu verras qu'il suffit de jouer sur quelques
constantes pour agrandir {a,z} ou le nombre de bits de la clé à craquer.

Pour en faire une version exhaustive, il suffirait de boucler de NK = 4
(32 bits) à NK = 128 (1024 bits) et de régler les constantes c1 et c2 pour
prendre en compte les collisions dues aux multiplications par 3 et 4, on
pourrait ainsi, EN MOINS D'UNE SECONDE, trouver n'importe quelle clé.

Pour ta gouverne, il me faudrait une grosse après-midi (allez, une
journée) pour faire cela et écrire un code plus pro.

Mais, pour ma part, j'en reste là. Tu es de mauvaise foi,

J'y vais selon mes convictions et ma compréhension des choses, et chacun à
son rythme. Libre à vous de m'accuser de la sorte.

le coup du texte "*Lzpacfiik", c'est assez petit.

L'amélioration de ton soft ne passera plus par moi.

Pas de problème là dessus. Car il est question juste de la clef
lorsqu'elle est chiffré. Dans la version sur Internet cette option est
désactivée. J'attend à la version 3.0 pour intégrer le code
d'identification.

Voilà. J'en ai terminé de flooder ce NG avec cette affaire. Remarque, ça
aura mis un peu d'ambiance :-).

Bien cordialement, mais avec rancune

Cela était bien évident depuis le début, et ça n'a pas aidé aux échanges.
Lorsqu'une personne vous enverra un ptit mot de mépris, essayez de voir ce
que ça vous fait au-dedans, et posez-vous la question si cela facilite les
rapports par la suite, surtout quand l'autre continue sans cesse sa façon de
communiquer. Mettez-vous maintenant dans la peau de celui qui subit cela en
partant. Pour vous, ça se prend mieux puisqu'il y en a quelques uns qui
faisaient comme vous (et ici je ne parle pas du côté technique comme je l'ai
dis maintes fois). Mon but à l'arrivé sur ce forum était de présenter mon
logiciel afin qu'on en donne son avis et non de tenter de M'écraser en
partant (et ici je ne parle pas du logiciel).

Donc je vous laisse là dessus et je ne m'attends pas à d'autres
communications avec vous (avec votre rancune), puisque pas vraiment
intéressant votre côté piqueur depuis le début. Je voudrais bien que ça
aille bien mais si vous ne voulez pas je n'y peux rien.

Au revoir

(Becoz *Lzpacfiik...).

--
AMcD®

http://arnold.mcdonald.free.fr/

"AMcD®" <arnold.mcdonald@free.fr> a écrit dans le message de news:
41b8b78c$0$9842$636a15ce@news.free.fr...

Raymond H. wrote:

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour
tenter de décrypter certaines clefs

Non, tu ne comprends pas. Tu n'as rien compris à ce que j'ai montré. Ou,
peut-être, tu ne veux pas comprendre.

Je n'ai pas tenté, j'ai réussi. Dans le domaine de la nuance, cela fait
une différence :-).

Mais vous avez tentez pour pouvoir réussir le bout que vous avez fait.
C'est ce que je veux dire.

même si son soft est limité.

Mon soft n'est pas limité car ce n'est pas un soft.

Mais oui, c'est un soft et 'soft' signifie 'mou', autrement dit ce n'est pas
du Hardware 'dur' mais sur software (logiciel; je parle du exe).

C'est une preuve de faisabilité. Je n'avais pas le temps d'écrire un truc
exhaustif. Je me suis donc contenté d'un exemple. Et cela suffit, car même
il n'y aurait qu'une faille, c'est déjà de trop.

Mais je vois que tu es têtu... Alors, si cela peut te rassurer, toujours
sur {a,z}, je peux maintenant te casser n'importe clé de 32 à 1024 bits.
Tu as bien lu ? N'importe laquelle de 32 à 1024. Veux-tu encore me tester
une nouvelle fois ?

Il
a un zèle pour ce genre de chose et ca aide à prendre conscience de
certaines choses.

Je n'ai aucun zèle pour cela.

Prenez au moins ce mot dans le sens de 'dévouement' selon le Petit
Robert. Mais bon! Si vous aimez mieux me contredire sur presque tout ce que
je dis pour tenter de vous plaire alors je subi.

J'ai arrêté de m'intéresser à la crypto il y a bien longtemps, depuis le
RSA, les clés asymétriques, etc. Mon truc c'est les virus et le hacking,
tu vois c'est loin de la crypto. Ce que je t'ai montré n'a rien à voir
avec la crypto.

Il n'est donc pas question de cryptologie ici? Autre chose pour me
contredire?

Et en plus j'avais déjà expliqué cela dans un autre message
concernant le temps d'exécution d'une procédure ne faisant des
calculs que pour une clef ayant un minimum de caractères et en
minuscule de a à z. On pourrait comparer par ce moyen les clefs d'à
peu près n'importe lequel des softs de cryptage en autant qu'on ait
quelques calculs pour le faire.

Tu ne comprends toujours pas, tu n'as rien compris à mon exposé, son but.
J'ai choisi {a,z} pour diverses raisons :

- Pour rédiger un texte, c'est plus facile d'utiliser {a,z} et de, par
exemple, de dire soit la clé "biniou" que soit la clé #@^$¨` ;
- Comme tu utilises des décalages de 2 bits (des multiplications par 4),
il y a évidemment des problèmes avec les modulos. Par exemple, lors de la
détermination des octets de chaque caractère de la clé, on a des
multiplications par 3, par 4, etc. Donc, si je prends le cas de 4, sur
l'ensemble des 256 caractères ASCII étendus, il y aura 4 groupes de 64
caratères (256/4) qui possèderont des octets égaux (enfin, certains), on
appelle ça des collisions. Dans ton cas, c'est facile à gérér puisqu'il me
suffirait de faire une table pour les 256 caractères et de comparer le
deuxième, troisième, etc. octet chiffré de chaque clé. Mais, comme déjà
expliqué, j'ai autre chose à faire. Mais, si tu veux, au lieu de prendre
{a,z}, mon exemple marche très bien sur {A,Z}u{[]^^_`}u{a,z} par exemple.
Il suffit d'utiliser un sous-ensemble de 64 caractères. Bref, l'ensemble
'{a,z} n'a rien à voir avec ma méthode. Comment ne comrpends-tu pas ça ?

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé
!

Ce n'est pas ce que je veux dire. Je parle de certains caractères ou
données pour la comparaison avec le chiffré pour compléter.

J'utilise une formule, une simple formule.

J'ose espérer que vous y connaissiez
quelque chose et que vous parlez pas seulement d'après ce que
d'autres vous disent! Cela peut prendre d'une fraction de seconde à
quelques secondes pour trouver ces quelques clefs via un soft créé à
cet effet avec une limitation de quelques caractères seulement. Il
y a quand même une différence avec une clef de 1024 qui ne se limite
pas à des minuscule de a à z.

Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z} je te dis
!!! C'est pas possible une mule pareille. Et si j'avais le temps, sur tout
le domaine de la table ASCII étendue.

Bon bien tant mieux pour vous et tant pis pour moi :)
Cela me montre de ne pas intégrer une clef dans le chiffré.
Pas de problème là dessus.

Et comme j'ai dis auparavant, pour
trouver une clef dans AllCrypter il faut, en plus des calculs, faire
des comparaisons dans une boucle pour trouver une clef dans
AllCrypter sinon c'est impossible sans la clef (en clair) elle-même.

Franchement, tu es de plus en plus ridicule.

On pourrait faire ainsi avec presque n'importe lequel
des logiciels de cryptage en autant de posséder suffisamment de
calculs pour le faire.

Il y a 1 (UN) calcul à faire, j'applique une formule ! Tu vas comprendre à
un moment donné ?

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

Merci du conseil.

mais y intégrer, si
désiré, un code qui l'identifie plutôt,

Si tu ne changes pas la formule de calcul de la clé, ça changera quoi ?

En effet je travaille déjà à la modifier, et c'est pourquoi le reste aussi
sera modifié puisque ca fonctionne ensemble.

C'est une leçon à en tirer.

Comment veux-tu tirer des leçons ? Tu ne comprends que ce que tu veux
comprendre et détourne jusqu'à ce que ça t'arrange !

Je parle humblement de tirer une leçon (du moins dans ce que je réalise)
mais encore une contradiction.

Mais comme j'ai
dit, il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! T'es vraiment bouché mon pauvre ami. Et si tu
crois que beaucoup de gens dépassent 12 caractères pour leurs clés, tu te
fais une très mauvaise idée de tes clients...

Mais bon! On doit avancer et se perfectionner dans nos algos si cela
est nécessaire (je parle pour moi-même).

Oh mais il était bien avancé mon programme ! Tiens, je suis bon prince,
voici la partie qui calcule (en affichant le détail !!!) les octets de
n'importe quelle clé multiple de 16 bits de AllCrypter, de 32 à 128 bits :

#define NK 6

int weak_index[16][17] = {
0,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 8 bits
1, 1,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 16 bits
2, 1, 2,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 24 bits
3, 2, 1, 3,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 32 bits
4, 2, 3, 1, 4,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 40 bits
5, 3, 2, 4, 1, 5,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 48 bits
6, 3, 4, 2, 5, 1, 6,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 56 bits
7, 4, 3, 5, 2, 6, 1, 7,
0,-1,-1,-1,-1,-1,-1,-1,-1, // 64 bits
8, 4, 5, 3, 6, 2, 7, 1, 8,
0,-1,-1,-1,-1,-1,-1,-1, // 72 bits
9, 5, 4, 6, 3, 7, 2, 8, 1, 9,
0,-1,-1,-1,-1,-1,-1, // 80 bits
10, 5, 6, 4, 7, 3, 8, 2, 9, 1,10,
0,-1,-1,-1,-1,-1, // 88 bits
11, 6, 5, 7, 4, 8, 3, 9, 2,10, 1,11,
0,-1,-1,-1,-1, // 96 bits
12, 6, 7, 5, 8, 4, 9, 3,10, 2,11, 1,12,
0,-1,-1,-1, // 104 bits
13, 7, 6, 8, 5, 9, 4,10, 3,11, 2,12, 1,13,
0,-1,-1, // 112 bits
14, 7, 8, 6, 9, 5,10, 4,11, 3,12, 2,13, 1,14,
0,-1, // 120 bits
15, 8, 7, 9, 6,10, 5,11, 4,12, 3,13, 2,14, 1,15,
0 // 128 bits
};
int i[NK] = { -1 };
int A[NK][4] = { -1 };
int z[2*NK] = { 0 };
int index0,index1,index2,index3 = 0;
int a,b,c,d;
int ASCIIStart = 97;
int c1 = 0x83;
int c2 = 0x40;

char keyToFind[] = "E9E0C1C6D1D3D5D4CDDAFD";

char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int j;

for ( j = 0; j < 2*NK; j++ ) org[j] = 129 + j*2;

for ( j = 0; j < 2*NK; j++ )
{
a = keyToFind[j*2];

b = keyToFind[j*2+1];

if ( a > 64 ) a -= 55;

if ( a > 47 ) a -= 48;

if ( b > 64 ) b -= 55;

if ( b > 47 ) b -= 48;

z[j] = a * 16 + b;
}

// in à i1

for ( j = 0; j < NK-1; j++ )
{
index0 = weak_index[NK-1][1+j];

// Premier

if ( j == 0 )
{
index1 = 1;

A[index0][index1] = z[ weak_index[NK-1][0] ];

i[index0] = ( A[index0][index1] - (c1+NK*2) ) / 4 + ASCIIStart;

index1 = 0;

index2 = NK-2;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 2;

index3 = index2 + 2;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
else
{
index0 = weak_index[NK-1][1+j];

index1 = 1;

A[index0][index1] = z[c] + org[c] - a;

i[index0] = ( A[index0][index1] - (c2+NK*2-2*j) ) / 3 + ASCIIStart;

index1 = 2;

A[index0][index1] = z[d] + org[d] - b;

index1 = 0;

index2 = c - 1;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 3;

index3 = d + 1;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
}

À la fin de ce code, tu as les octets i1-i2N-1 (dans la table i[]) de la
clé dont les octets figurent dans keyToFind[]. Le dernier octet à calculer
(le premier de la clé), i0, il suffit de brute-forcer sur {a,z} en
calculant les octets de la clé, K0 à K(2NK-1) et de comparer à
keyToFind[]. Je n'ai pas mis tout le code hein. Et c'est un peu plus
complexe que les autres exemples, c'est sûr...

Compare avec le code du 80 bits et tu comprendras vite ce qui se passe
:-).

Étudie bien le code, tu verras qu'il suffit de jouer sur quelques
constantes pour agrandir {a,z} ou le nombre de bits de la clé à craquer.

Pour en faire une version exhaustive, il suffirait de boucler de NK = 4
(32 bits) à NK = 128 (1024 bits) et de régler les constantes c1 et c2 pour
prendre en compte les collisions dues aux multiplications par 3 et 4, on
pourrait ainsi, EN MOINS D'UNE SECONDE, trouver n'importe quelle clé.

Pour ta gouverne, il me faudrait une grosse après-midi (allez, une
journée) pour faire cela et écrire un code plus pro.

Mais, pour ma part, j'en reste là. Tu es de mauvaise foi,

J'y vais selon mes convictions et ma compréhension des choses, et chacun à
son rythme. Libre à vous de m'accuser de la sorte.

le coup du texte "*Lzpacfiik", c'est assez petit.

L'amélioration de ton soft ne passera plus par moi.

Pas de problème là dessus. Car il est question juste de la clef
lorsqu'elle est chiffré. Dans la version sur Internet cette option est
désactivée. J'attend à la version 3.0 pour intégrer le code
d'identification.

Voilà. J'en ai terminé de flooder ce NG avec cette affaire. Remarque, ça
aura mis un peu d'ambiance :-).

Bien cordialement, mais avec rancune

Cela était bien évident depuis le début, et ça n'a pas aidé aux échanges.
Lorsqu'une personne vous enverra un ptit mot de mépris, essayez de voir ce
que ça vous fait au-dedans, et posez-vous la question si cela facilite les
rapports par la suite, surtout quand l'autre continue sans cesse sa façon de
communiquer. Mettez-vous maintenant dans la peau de celui qui subit cela en
partant. Pour vous, ça se prend mieux puisqu'il y en a quelques uns qui
faisaient comme vous (et ici je ne parle pas du côté technique comme je l'ai
dis maintes fois). Mon but à l'arrivé sur ce forum était de présenter mon
logiciel afin qu'on en donne son avis et non de tenter de M'écraser en
partant (et ici je ne parle pas du logiciel).

Donc je vous laisse là dessus et je ne m'attends pas à d'autres
communications avec vous (avec votre rancune), puisque pas vraiment
intéressant votre côté piqueur depuis le début. Je voudrais bien que ça
aille bien mais si vous ne voulez pas je n'y peux rien.

Au revoir

(Becoz *Lzpacfiik...).

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

"AMcD®" a écrit dans le message de news:
41b8b78c$0$9842$

Raymond H. wrote:

Ailleurs, j'ai déjà félicité l'auteur du soft pour son travail pour
tenter de décrypter certaines clefs

Non, tu ne comprends pas. Tu n'as rien compris à ce que j'ai montré. Ou,
peut-être, tu ne veux pas comprendre.

Je n'ai pas tenté, j'ai réussi. Dans le domaine de la nuance, cela fait
une différence :-).

Mais vous avez tentez pour pouvoir réussir le bout que vous avez fait.
C'est ce que je veux dire.

même si son soft est limité.

Mon soft n'est pas limité car ce n'est pas un soft.

Mais oui, c'est un soft et 'soft' signifie 'mou', autrement dit ce n'est pas
du Hardware 'dur' mais sur software (logiciel; je parle du exe).

C'est une preuve de faisabilité. Je n'avais pas le temps d'écrire un truc
exhaustif. Je me suis donc contenté d'un exemple. Et cela suffit, car même
il n'y aurait qu'une faille, c'est déjà de trop.

Mais je vois que tu es têtu... Alors, si cela peut te rassurer, toujours
sur {a,z}, je peux maintenant te casser n'importe clé de 32 à 1024 bits.
Tu as bien lu ? N'importe laquelle de 32 à 1024. Veux-tu encore me tester
une nouvelle fois ?

Il
a un zèle pour ce genre de chose et ca aide à prendre conscience de
certaines choses.

Je n'ai aucun zèle pour cela.

Prenez au moins ce mot dans le sens de 'dévouement' selon le Petit
Robert. Mais bon! Si vous aimez mieux me contredire sur presque tout ce que
je dis pour tenter de vous plaire alors je subi.

J'ai arrêté de m'intéresser à la crypto il y a bien longtemps, depuis le
RSA, les clés asymétriques, etc. Mon truc c'est les virus et le hacking,
tu vois c'est loin de la crypto. Ce que je t'ai montré n'a rien à voir
avec la crypto.

Il n'est donc pas question de cryptologie ici? Autre chose pour me
contredire?

Et en plus j'avais déjà expliqué cela dans un autre message
concernant le temps d'exécution d'une procédure ne faisant des
calculs que pour une clef ayant un minimum de caractères et en
minuscule de a à z. On pourrait comparer par ce moyen les clefs d'à
peu près n'importe lequel des softs de cryptage en autant qu'on ait
quelques calculs pour le faire.

Tu ne comprends toujours pas, tu n'as rien compris à mon exposé, son but.
J'ai choisi {a,z} pour diverses raisons :

- Pour rédiger un texte, c'est plus facile d'utiliser {a,z} et de, par
exemple, de dire soit la clé "biniou" que soit la clé #@^$¨` ;
- Comme tu utilises des décalages de 2 bits (des multiplications par 4),
il y a évidemment des problèmes avec les modulos. Par exemple, lors de la
détermination des octets de chaque caractère de la clé, on a des
multiplications par 3, par 4, etc. Donc, si je prends le cas de 4, sur
l'ensemble des 256 caractères ASCII étendus, il y aura 4 groupes de 64
caratères (256/4) qui possèderont des octets égaux (enfin, certains), on
appelle ça des collisions. Dans ton cas, c'est facile à gérér puisqu'il me
suffirait de faire une table pour les 256 caractères et de comparer le
deuxième, troisième, etc. octet chiffré de chaque clé. Mais, comme déjà
expliqué, j'ai autre chose à faire. Mais, si tu veux, au lieu de prendre
{a,z}, mon exemple marche très bien sur {A,Z}u{[]^^_`}u{a,z} par exemple.
Il suffit d'utiliser un sous-ensemble de 64 caractères. Bref, l'ensemble
'{a,z} n'a rien à voir avec ma méthode. Comment ne comrpends-tu pas ça ?

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé
!

Ce n'est pas ce que je veux dire. Je parle de certains caractères ou
données pour la comparaison avec le chiffré pour compléter.

J'utilise une formule, une simple formule.

J'ose espérer que vous y connaissiez
quelque chose et que vous parlez pas seulement d'après ce que
d'autres vous disent! Cela peut prendre d'une fraction de seconde à
quelques secondes pour trouver ces quelques clefs via un soft créé à
cet effet avec une limitation de quelques caractères seulement. Il
y a quand même une différence avec une clef de 1024 qui ne se limite
pas à des minuscule de a à z.

Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z} je te dis
!!! C'est pas possible une mule pareille. Et si j'avais le temps, sur tout
le domaine de la table ASCII étendue.

Bon bien tant mieux pour vous et tant pis pour moi :)
Cela me montre de ne pas intégrer une clef dans le chiffré.
Pas de problème là dessus.

Et comme j'ai dis auparavant, pour
trouver une clef dans AllCrypter il faut, en plus des calculs, faire
des comparaisons dans une boucle pour trouver une clef dans
AllCrypter sinon c'est impossible sans la clef (en clair) elle-même.

Franchement, tu es de plus en plus ridicule.

On pourrait faire ainsi avec presque n'importe lequel
des logiciels de cryptage en autant de posséder suffisamment de
calculs pour le faire.

Il y a 1 (UN) calcul à faire, j'applique une formule ! Tu vas comprendre à
un moment donné ?

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

Merci du conseil.

mais y intégrer, si
désiré, un code qui l'identifie plutôt,

Si tu ne changes pas la formule de calcul de la clé, ça changera quoi ?

En effet je travaille déjà à la modifier, et c'est pourquoi le reste aussi
sera modifié puisque ca fonctionne ensemble.

C'est une leçon à en tirer.

Comment veux-tu tirer des leçons ? Tu ne comprends que ce que tu veux
comprendre et détourne jusqu'à ce que ça t'arrange !

Je parle humblement de tirer une leçon (du moins dans ce que je réalise)
mais encore une contradiction.

Mais comme j'ai
dit, il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! T'es vraiment bouché mon pauvre ami. Et si tu
crois que beaucoup de gens dépassent 12 caractères pour leurs clés, tu te
fais une très mauvaise idée de tes clients...

Mais bon! On doit avancer et se perfectionner dans nos algos si cela
est nécessaire (je parle pour moi-même).

Oh mais il était bien avancé mon programme ! Tiens, je suis bon prince,
voici la partie qui calcule (en affichant le détail !!!) les octets de
n'importe quelle clé multiple de 16 bits de AllCrypter, de 32 à 128 bits :

#define NK 6

int weak_index[16][17] = {
0,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 8 bits
1, 1,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 16 bits
2, 1, 2,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 24 bits
3, 2, 1, 3,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 32 bits
4, 2, 3, 1, 4,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 40 bits
5, 3, 2, 4, 1, 5,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 48 bits
6, 3, 4, 2, 5, 1, 6,
0,-1,-1,-1,-1,-1,-1,-1,-1,-1, // 56 bits
7, 4, 3, 5, 2, 6, 1, 7,
0,-1,-1,-1,-1,-1,-1,-1,-1, // 64 bits
8, 4, 5, 3, 6, 2, 7, 1, 8,
0,-1,-1,-1,-1,-1,-1,-1, // 72 bits
9, 5, 4, 6, 3, 7, 2, 8, 1, 9,
0,-1,-1,-1,-1,-1,-1, // 80 bits
10, 5, 6, 4, 7, 3, 8, 2, 9, 1,10,
0,-1,-1,-1,-1,-1, // 88 bits
11, 6, 5, 7, 4, 8, 3, 9, 2,10, 1,11,
0,-1,-1,-1,-1, // 96 bits
12, 6, 7, 5, 8, 4, 9, 3,10, 2,11, 1,12,
0,-1,-1,-1, // 104 bits
13, 7, 6, 8, 5, 9, 4,10, 3,11, 2,12, 1,13,
0,-1,-1, // 112 bits
14, 7, 8, 6, 9, 5,10, 4,11, 3,12, 2,13, 1,14,
0,-1, // 120 bits
15, 8, 7, 9, 6,10, 5,11, 4,12, 3,13, 2,14, 1,15,
0 // 128 bits
};
int i[NK] = { -1 };
int A[NK][4] = { -1 };
int z[2*NK] = { 0 };
int index0,index1,index2,index3 = 0;
int a,b,c,d;
int ASCIIStart = 97;
int c1 = 0x83;
int c2 = 0x40;

char keyToFind[] = "E9E0C1C6D1D3D5D4CDDAFD";

char key[NK+1];
char keyTemp[2*NK*2+1];
int org[2*NK];
int j;

for ( j = 0; j < 2*NK; j++ ) org[j] = 129 + j*2;

for ( j = 0; j < 2*NK; j++ )
{
a = keyToFind[j*2];

b = keyToFind[j*2+1];

if ( a > 64 ) a -= 55;

if ( a > 47 ) a -= 48;

if ( b > 64 ) b -= 55;

if ( b > 47 ) b -= 48;

z[j] = a * 16 + b;
}

// in à i1

for ( j = 0; j < NK-1; j++ )
{
index0 = weak_index[NK-1][1+j];

// Premier

if ( j == 0 )
{
index1 = 1;

A[index0][index1] = z[ weak_index[NK-1][0] ];

i[index0] = ( A[index0][index1] - (c1+NK*2) ) / 4 + ASCIIStart;

index1 = 0;

index2 = NK-2;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 2;

index3 = index2 + 2;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
else
{
index0 = weak_index[NK-1][1+j];

index1 = 1;

A[index0][index1] = z[c] + org[c] - a;

i[index0] = ( A[index0][index1] - (c2+NK*2-2*j) ) / 3 + ASCIIStart;

index1 = 2;

A[index0][index1] = z[d] + org[d] - b;

index1 = 0;

index2 = c - 1;

c = index2;

A[index0][index1] = ( org[index2] + ( i[index0]-32 ) ) % 256;

a = A[index0][index1];

index1 = 3;

index3 = d + 1;

d = index3;

A[index0][index1] = ( org[index3] + ( i[index0]-32 ) * 3 ) % 256;

b = A[index0][index1];
}
}

À la fin de ce code, tu as les octets i1-i2N-1 (dans la table i[]) de la
clé dont les octets figurent dans keyToFind[]. Le dernier octet à calculer
(le premier de la clé), i0, il suffit de brute-forcer sur {a,z} en
calculant les octets de la clé, K0 à K(2NK-1) et de comparer à
keyToFind[]. Je n'ai pas mis tout le code hein. Et c'est un peu plus
complexe que les autres exemples, c'est sûr...

Compare avec le code du 80 bits et tu comprendras vite ce qui se passe
:-).

Étudie bien le code, tu verras qu'il suffit de jouer sur quelques
constantes pour agrandir {a,z} ou le nombre de bits de la clé à craquer.

Pour en faire une version exhaustive, il suffirait de boucler de NK = 4
(32 bits) à NK = 128 (1024 bits) et de régler les constantes c1 et c2 pour
prendre en compte les collisions dues aux multiplications par 3 et 4, on
pourrait ainsi, EN MOINS D'UNE SECONDE, trouver n'importe quelle clé.

Pour ta gouverne, il me faudrait une grosse après-midi (allez, une
journée) pour faire cela et écrire un code plus pro.

Mais, pour ma part, j'en reste là. Tu es de mauvaise foi,

J'y vais selon mes convictions et ma compréhension des choses, et chacun à
son rythme. Libre à vous de m'accuser de la sorte.

le coup du texte "*Lzpacfiik", c'est assez petit.

L'amélioration de ton soft ne passera plus par moi.

Pas de problème là dessus. Car il est question juste de la clef
lorsqu'elle est chiffré. Dans la version sur Internet cette option est
désactivée. J'attend à la version 3.0 pour intégrer le code
d'identification.

Voilà. J'en ai terminé de flooder ce NG avec cette affaire. Remarque, ça
aura mis un peu d'ambiance :-).

Bien cordialement, mais avec rancune

Cela était bien évident depuis le début, et ça n'a pas aidé aux échanges.
Lorsqu'une personne vous enverra un ptit mot de mépris, essayez de voir ce
que ça vous fait au-dedans, et posez-vous la question si cela facilite les
rapports par la suite, surtout quand l'autre continue sans cesse sa façon de
communiquer. Mettez-vous maintenant dans la peau de celui qui subit cela en
partant. Pour vous, ça se prend mieux puisqu'il y en a quelques uns qui
faisaient comme vous (et ici je ne parle pas du côté technique comme je l'ai
dis maintes fois). Mon but à l'arrivé sur ce forum était de présenter mon
logiciel afin qu'on en donne son avis et non de tenter de M'écraser en
partant (et ici je ne parle pas du logiciel).

Donc je vous laisse là dessus et je ne m'attends pas à d'autres
communications avec vous (avec votre rancune), puisque pas vraiment
intéressant votre côté piqueur depuis le début. Je voudrais bien que ça
aille bien mais si vous ne voulez pas je n'y peux rien.

Au revoir

(Becoz *Lzpacfiik...).

--
AMcD®

http://arnold.mcdonald.free.fr/

Arm7

09/12/2004 à 23:48

Le 1), c'est votre XOR initial (il a pour but d'egaliser
le nombre de 1 et de 0). Le 2) c'est l'ensemble des
permutations.

Encore que statistiquement, la quantité de 1 et de 0 restera inchangée...
En plus l'algo n'est pas de moi. Et il date de 1999 si j'ai bonne mémoire.

Pour resumer, la robustesse de ce systeme est directement
liee a celle du generateur psudo-aleatoire utilise'. Je
reprends donc a mon compte une remarque interessante d'un
des contributeurs de sci.crypt :

En quoi cette methode est-elle plus robuste qu'un simple
XOR effectue' entre le message a chiffrer et un ensemble
de valeurs generees par un generateur psudo-aleatoire
qui utilise la clef comme graine ?

J'ai bien une idée de réponse, mais ca va encore dégénérer !

Sylvain

10/12/2004 à 01:40

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé !
[..]
Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z}

je me suis permis de réécrire ta routine en simplifiant un peu les
calculs s'annulant, il vient:

#include <conio.h>
#include <string.h>

typedef unsigned char byte;
#define null NULL

byte char2digit(const char c)
{
if (c >= '0' && c <= '9')
return (byte)(c - '0');
if (c >= 'a' && c <= 'f')
return (byte)(c - 'a' + 10);
if (c >= 'A' && c <= 'F')
return (byte)(c - 'A' + 10);
return (byte) 0;
}

void main()
{
char keyToFind[257];
strcpy(keyToFind, "E1E1CB9CA7AADCBBA1979DB3D6E0AFBEC3FD05DF");
//strcpy(keyToFind, "E9D6AED79EBCADD4AD97A1C6D9B6CCBFF4CC0DBF");

register nbChar = strlen(keyToFind);
// get length of key
int size = nbChar >> 1;

// compute hexa value of obfuscated key
byte obKey[32];
for (register int i = 0; i < size; ++i)
obKey[i] = (char2digit(keyToFind[2 * i]) << 4) |
char2digit(keyToFind[2 * i + 1]);

// plain key placeholder
char key[32];
memset(key, 0, 32 * sizeof(char));

// all char but the first are recovered from obfuscated key
key[5] = ( obKey[9] - 0x97 ) / 4 + 'a';
key[4] = ( obKey[8] - key[5] - 0x32 ) / 3 + 'a';
key[6] = ( obKey[7] - key[4] - 0x30 ) / 3 + 'a';
key[3] = ( obKey[6] - key[6] - 0x2E ) / 3 + 'a';
key[7] = ( obKey[5] - key[3] - 0x2C ) / 3 + 'a';
key[2] = ( obKey[4] - key[7] - 0x2A ) / 3 + 'a';
key[8] = ( obKey[3] - key[2] - 0x28 ) / 3 + 'a';
key[1] = ( obKey[2] - key[8] - 0x26 ) / 3 + 'a';
key[9] = ( obKey[1] - key[1] - 0x24 ) / 3 + 'a';

// look for the first character of key !...

for (register unsigned char c = 'a'; c <= 'z'; ++c){

byte K0 = key[9] + 3 * c + 1;
byte K18 = 3 * key[9] + c + 37; // useless

if (K0 == obKey[0] && K18 == obKey[18]){
key[0] = c;
printf("ntatatata tataaaaa! found! key = %s", key);
break;
}
}
}

on constate:
- les caractères N+1 à 2*N de la "clé masqué" ne servent à rien (pour
vérifier la clé saisie, p.e. servent-ils au chiffrement du msg),
- un clé de N bits (N grand) se casse aussi simplement qu'une clé courte
car seul la reconstruction du premier caractère doit être effectuée,
- (corrolaire) le temps de calcul de la clé n'est pas proportionel à sa
taille.

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !

il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! [...]

et a voir la construction de la clé, il n'y a objectivement aucune
différence - une clé de 32 bits et "aussi forte" qu'une clé de 2048 bits

Sylvain.

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé !
[..]
Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z}

je me suis permis de réécrire ta routine en simplifiant un peu les
calculs s'annulant, il vient:

#include <conio.h>
#include <string.h>

typedef unsigned char byte;
#define null NULL

byte char2digit(const char c)
{
if (c >= '0' && c <= '9')
return (byte)(c - '0');
if (c >= 'a' && c <= 'f')
return (byte)(c - 'a' + 10);
if (c >= 'A' && c <= 'F')
return (byte)(c - 'A' + 10);
return (byte) 0;
}

void main()
{
char keyToFind[257];
strcpy(keyToFind, "E1E1CB9CA7AADCBBA1979DB3D6E0AFBEC3FD05DF");
//strcpy(keyToFind, "E9D6AED79EBCADD4AD97A1C6D9B6CCBFF4CC0DBF");

register nbChar = strlen(keyToFind);
// get length of key
int size = nbChar >> 1;

// compute hexa value of obfuscated key
byte obKey[32];
for (register int i = 0; i < size; ++i)
obKey[i] = (char2digit(keyToFind[2 * i]) << 4) |
char2digit(keyToFind[2 * i + 1]);

// plain key placeholder
char key[32];
memset(key, 0, 32 * sizeof(char));

// all char but the first are recovered from obfuscated key
key[5] = ( obKey[9] - 0x97 ) / 4 + 'a';
key[4] = ( obKey[8] - key[5] - 0x32 ) / 3 + 'a';
key[6] = ( obKey[7] - key[4] - 0x30 ) / 3 + 'a';
key[3] = ( obKey[6] - key[6] - 0x2E ) / 3 + 'a';
key[7] = ( obKey[5] - key[3] - 0x2C ) / 3 + 'a';
key[2] = ( obKey[4] - key[7] - 0x2A ) / 3 + 'a';
key[8] = ( obKey[3] - key[2] - 0x28 ) / 3 + 'a';
key[1] = ( obKey[2] - key[8] - 0x26 ) / 3 + 'a';
key[9] = ( obKey[1] - key[1] - 0x24 ) / 3 + 'a';

// look for the first character of key !...

for (register unsigned char c = 'a'; c <= 'z'; ++c){

byte K0 = key[9] + 3 * c + 1;
byte K18 = 3 * key[9] + c + 37; // useless

if (K0 == obKey[0] && K18 == obKey[18]){
key[0] = c;
printf("ntatatata tataaaaa! found! key = %s", key);
break;
}
}
}

on constate:
- les caractères N+1 à 2*N de la "clé masqué" ne servent à rien (pour
vérifier la clé saisie, p.e. servent-ils au chiffrement du msg),
- un clé de N bits (N grand) se casse aussi simplement qu'une clé courte
car seul la reconstruction du premier caractère doit être effectuée,
- (corrolaire) le temps de calcul de la clé n'est pas proportionel à sa
taille.

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !

il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! [...]

et a voir la construction de la clé, il n'y a objectivement aucune
différence - une clé de 32 bits et "aussi forte" qu'une clé de 2048 bits

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

Enfin, je je balaye pas un ensemble de clé bon sang !!!! Je calcule ta clé !
[..]
Je te craque n'importe quelle clé de 32 à 1024 bits sur {a,z}

je me suis permis de réécrire ta routine en simplifiant un peu les
calculs s'annulant, il vient:

#include <conio.h>
#include <string.h>

typedef unsigned char byte;
#define null NULL

byte char2digit(const char c)
{
if (c >= '0' && c <= '9')
return (byte)(c - '0');
if (c >= 'a' && c <= 'f')
return (byte)(c - 'a' + 10);
if (c >= 'A' && c <= 'F')
return (byte)(c - 'A' + 10);
return (byte) 0;
}

void main()
{
char keyToFind[257];
strcpy(keyToFind, "E1E1CB9CA7AADCBBA1979DB3D6E0AFBEC3FD05DF");
//strcpy(keyToFind, "E9D6AED79EBCADD4AD97A1C6D9B6CCBFF4CC0DBF");

register nbChar = strlen(keyToFind);
// get length of key
int size = nbChar >> 1;

// compute hexa value of obfuscated key
byte obKey[32];
for (register int i = 0; i < size; ++i)
obKey[i] = (char2digit(keyToFind[2 * i]) << 4) |
char2digit(keyToFind[2 * i + 1]);

// plain key placeholder
char key[32];
memset(key, 0, 32 * sizeof(char));

// all char but the first are recovered from obfuscated key
key[5] = ( obKey[9] - 0x97 ) / 4 + 'a';
key[4] = ( obKey[8] - key[5] - 0x32 ) / 3 + 'a';
key[6] = ( obKey[7] - key[4] - 0x30 ) / 3 + 'a';
key[3] = ( obKey[6] - key[6] - 0x2E ) / 3 + 'a';
key[7] = ( obKey[5] - key[3] - 0x2C ) / 3 + 'a';
key[2] = ( obKey[4] - key[7] - 0x2A ) / 3 + 'a';
key[8] = ( obKey[3] - key[2] - 0x28 ) / 3 + 'a';
key[1] = ( obKey[2] - key[8] - 0x26 ) / 3 + 'a';
key[9] = ( obKey[1] - key[1] - 0x24 ) / 3 + 'a';

// look for the first character of key !...

for (register unsigned char c = 'a'; c <= 'z'; ++c){

byte K0 = key[9] + 3 * c + 1;
byte K18 = 3 * key[9] + c + 37; // useless

if (K0 == obKey[0] && K18 == obKey[18]){
key[0] = c;
printf("ntatatata tataaaaa! found! key = %s", key);
break;
}
}
}

on constate:
- les caractères N+1 à 2*N de la "clé masqué" ne servent à rien (pour
vérifier la clé saisie, p.e. servent-ils au chiffrement du msg),
- un clé de N bits (N grand) se casse aussi simplement qu'une clé courte
car seul la reconstruction du premier caractère doit être effectuée,
- (corrolaire) le temps de calcul de la clé n'est pas proportionel à sa
taille.

Et c'est là que le soft du AMcD donne un enseignement: c'est-à-dire
qu'il faut être très prudent dans le fait d'intégrer une clef au sein
du cryptogramme et éviter de l'intégrer au début du cryptogramme et
je dirait même de ne pas l'intégrer du tout

Ben oui, ne pas l'intégrer est la seule solution.

on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !

il y a une différence entre des minuscule de a à z et presque
tous les caractères de la table des caractères et en plus en 1024.

Non, il n'y en a aucune !!! [...]

et a voir la construction de la clé, il n'y a objectivement aucune
différence - une clé de 32 bits et "aussi forte" qu'une clé de 2048 bits

Sylvain.

AMcD®

10/12/2004 à 02:59

Sylvain wrote:

je me suis permis de réécrire ta routine en simplifiant un peu les
calculs s'annulant, il vient:

Erf, il n'y a pas de mal :-). Faut bien avouer que c'est codé un peu
n'importe comment. J'avais prévu de faire une version super pro, avec
matrices et tout et tout, mais bon, je n'ai pas le temps et la mauvaise foi
du gars m'a découragé. Alors, c'est codé à l'instinct. C'est sûr, quand tu
vois la traduction hexa des z[], il y a de quoi se marrer... Pour être
honnête, le premier bout de code je l'ai fait en regardant Columbo à la TV
la semaine dernière et j'ai enchaîné ensuite dessus. Je n'ai pas franchement
eu le temps d'écrire/étudier la chose à fond.

Bien étudié et rédigé, je pense que cela aurait pu faire un bon petit cas
d'école de diffing. Mais bon, là je suis passé à autre chose. En ce qui me
concerne, c'est over...

on constate:
- les caractères N+1 à 2*N de la "clé masqué" ne servent à rien (pour
vérifier la clé saisie, p.e. servent-ils au chiffrement du msg),

Oui, bonne remarque. Au départ, je brute-forçais tout. Puis, peu à peu, avec
les différentes versions du code, j'ai enlevé les octets de la clé un par un
de la boucle. Jusqu'au dernier, qu'il me restait à "mettre en équation".
Mais bon, un brute-force sur 255 code ASCII (au maximum), ça va, c'est pas
la mort :-).

Quand tu écris le code pour 2-3 exemples concrets (par exemple 32 bits ou 48
bits), tu remarques évidemment (voir schémas de mes pdf) la chose que tu
décrit. Note également que le dernier octet de la clé doit servir à autre
chose, vu que si tu codes un fichier vide (ça aussi, quelle bonne blague !)
ou un fichier non-vide avec une même clé, ce dernier octet diffère
légèrement.

- un clé de N bits (N grand) se casse aussi simplement qu'une clé
courte car seul la reconstruction du premier caractère doit être
effectuée, - (corrolaire) le temps de calcul de la clé n'est pas
proportionel à sa taille.

L'auteur a-t-il bien intégré cela ?

on note que "l'auteur" (sic) a, dès les premières remarques postées
ici, libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !

Oh, moi, ce qui m'a fait le plus marrer, c'est qu'un soft aussi génial a vu
sortir 2 nouvelles versions en 1 semaine :-).

et a voir la construction de la clé, il n'y a objectivement aucune
différence - une clé de 32 bits et "aussi forte" qu'une clé de 2048
bits

Eh oui ! J'avais commençé a essayer, pour convaincre l'animal, de couvrir
tout le domaine ASCII et donc de trouver une méthode rapide pour traiter les
collisions à cause du modulo. Et puis je me suis dit que c'était vraiment
perdre du temps pour rien : d'une le gars semble aveugle et de deux, un soft
de crypto, dès que tu trouves une faille [1], ben c'est pas la peine d'aller
plus loin.

Merci pour ton intervention.

[1] Bien qu'ici, ce ne soit pas la partie cryptographique proprement dite
qui soit faible, mais plutôt le concept de stocker une clé facilement
inversible. Pour être juste, je ne parierai pas que la partie
cryptographique casse des briques non plus. Un post de Erwann ABALEA (je
crois) a titillé mon esprit... Mais bon, pas le temps.

--
AMcD®

http://arnold.mcdonald.free.fr/

Sylvain wrote:

je me suis permis de réécrire ta routine en simplifiant un peu les
calculs s'annulant, il vient:

Erf, il n'y a pas de mal :-). Faut bien avouer que c'est codé un peu
n'importe comment. J'avais prévu de faire une version super pro, avec
matrices et tout et tout, mais bon, je n'ai pas le temps et la mauvaise foi
du gars m'a découragé. Alors, c'est codé à l'instinct. C'est sûr, quand tu
vois la traduction hexa des z[], il y a de quoi se marrer... Pour être
honnête, le premier bout de code je l'ai fait en regardant Columbo à la TV
la semaine dernière et j'ai enchaîné ensuite dessus. Je n'ai pas franchement
eu le temps d'écrire/étudier la chose à fond.

Bien étudié et rédigé, je pense que cela aurait pu faire un bon petit cas
d'école de diffing. Mais bon, là je suis passé à autre chose. En ce qui me
concerne, c'est over...

on constate:
- les caractères N+1 à 2*N de la "clé masqué" ne servent à rien (pour
vérifier la clé saisie, p.e. servent-ils au chiffrement du msg),

Oui, bonne remarque. Au départ, je brute-forçais tout. Puis, peu à peu, avec
les différentes versions du code, j'ai enlevé les octets de la clé un par un
de la boucle. Jusqu'au dernier, qu'il me restait à "mettre en équation".
Mais bon, un brute-force sur 255 code ASCII (au maximum), ça va, c'est pas
la mort :-).

Quand tu écris le code pour 2-3 exemples concrets (par exemple 32 bits ou 48
bits), tu remarques évidemment (voir schémas de mes pdf) la chose que tu
décrit. Note également que le dernier octet de la clé doit servir à autre
chose, vu que si tu codes un fichier vide (ça aussi, quelle bonne blague !)
ou un fichier non-vide avec une même clé, ce dernier octet diffère
légèrement.

- un clé de N bits (N grand) se casse aussi simplement qu'une clé
courte car seul la reconstruction du premier caractère doit être
effectuée, - (corrolaire) le temps de calcul de la clé n'est pas
proportionel à sa taille.

L'auteur a-t-il bien intégré cela ?

on note que "l'auteur" (sic) a, dès les premières remarques postées
ici, libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !

Oh, moi, ce qui m'a fait le plus marrer, c'est qu'un soft aussi génial a vu
sortir 2 nouvelles versions en 1 semaine :-).

et a voir la construction de la clé, il n'y a objectivement aucune
différence - une clé de 32 bits et "aussi forte" qu'une clé de 2048
bits

Eh oui ! J'avais commençé a essayer, pour convaincre l'animal, de couvrir
tout le domaine ASCII et donc de trouver une méthode rapide pour traiter les
collisions à cause du modulo. Et puis je me suis dit que c'était vraiment
perdre du temps pour rien : d'une le gars semble aveugle et de deux, un soft
de crypto, dès que tu trouves une faille [1], ben c'est pas la peine d'aller
plus loin.

Merci pour ton intervention.

[1] Bien qu'ici, ce ne soit pas la partie cryptographique proprement dite
qui soit faible, mais plutôt le concept de stocker une clé facilement
inversible. Pour être juste, je ne parierai pas que la partie
cryptographique casse des briques non plus. Un post de Erwann ABALEA (je
crois) a titillé mon esprit... Mais bon, pas le temps.

--
AMcD®

http://arnold.mcdonald.free.fr/

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

je me suis permis de réécrire ta routine en simplifiant un peu les
calculs s'annulant, il vient:

Erf, il n'y a pas de mal :-). Faut bien avouer que c'est codé un peu
n'importe comment. J'avais prévu de faire une version super pro, avec
matrices et tout et tout, mais bon, je n'ai pas le temps et la mauvaise foi
du gars m'a découragé. Alors, c'est codé à l'instinct. C'est sûr, quand tu
vois la traduction hexa des z[], il y a de quoi se marrer... Pour être
honnête, le premier bout de code je l'ai fait en regardant Columbo à la TV
la semaine dernière et j'ai enchaîné ensuite dessus. Je n'ai pas franchement
eu le temps d'écrire/étudier la chose à fond.

Bien étudié et rédigé, je pense que cela aurait pu faire un bon petit cas
d'école de diffing. Mais bon, là je suis passé à autre chose. En ce qui me
concerne, c'est over...

on constate:
- les caractères N+1 à 2*N de la "clé masqué" ne servent à rien (pour
vérifier la clé saisie, p.e. servent-ils au chiffrement du msg),

Oui, bonne remarque. Au départ, je brute-forçais tout. Puis, peu à peu, avec
les différentes versions du code, j'ai enlevé les octets de la clé un par un
de la boucle. Jusqu'au dernier, qu'il me restait à "mettre en équation".
Mais bon, un brute-force sur 255 code ASCII (au maximum), ça va, c'est pas
la mort :-).

Quand tu écris le code pour 2-3 exemples concrets (par exemple 32 bits ou 48
bits), tu remarques évidemment (voir schémas de mes pdf) la chose que tu
décrit. Note également que le dernier octet de la clé doit servir à autre
chose, vu que si tu codes un fichier vide (ça aussi, quelle bonne blague !)
ou un fichier non-vide avec une même clé, ce dernier octet diffère
légèrement.

- un clé de N bits (N grand) se casse aussi simplement qu'une clé
courte car seul la reconstruction du premier caractère doit être
effectuée, - (corrolaire) le temps de calcul de la clé n'est pas
proportionel à sa taille.

L'auteur a-t-il bien intégré cela ?

on note que "l'auteur" (sic) a, dès les premières remarques postées
ici, libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !

Oh, moi, ce qui m'a fait le plus marrer, c'est qu'un soft aussi génial a vu
sortir 2 nouvelles versions en 1 semaine :-).

et a voir la construction de la clé, il n'y a objectivement aucune
différence - une clé de 32 bits et "aussi forte" qu'une clé de 2048
bits

Eh oui ! J'avais commençé a essayer, pour convaincre l'animal, de couvrir
tout le domaine ASCII et donc de trouver une méthode rapide pour traiter les
collisions à cause du modulo. Et puis je me suis dit que c'était vraiment
perdre du temps pour rien : d'une le gars semble aveugle et de deux, un soft
de crypto, dès que tu trouves une faille [1], ben c'est pas la peine d'aller
plus loin.

Merci pour ton intervention.

[1] Bien qu'ici, ce ne soit pas la partie cryptographique proprement dite
qui soit faible, mais plutôt le concept de stocker une clé facilement
inversible. Pour être juste, je ne parierai pas que la partie
cryptographique casse des briques non plus. Un post de Erwann ABALEA (je
crois) a titillé mon esprit... Mais bon, pas le temps.

--
AMcD®

http://arnold.mcdonald.free.fr/

Raymond H.

10/12/2004 à 03:55

"arm7" a écrit dans le message de news:
41b715c4$0$2786$

AMcD®

http://arnold.mcdonald.free.fr/

J'ai envoyé le .exe...

Bonjour M. McDonald,

ce exe peut-il tourner sur Dos ou Windows? si oui puis-je l'avoir
aussi? :)
a+
Raymond H.

Raymond H.

10/12/2004 à 07:28

"Jacques Caron" a écrit dans le message de news:

Bon,

Il a pas bientôt fini le monsieur? Le monsieur il prétend que son soft est
un outil de chiffrement de "haute qualité" que personne même pas lui il
peut déchiffrer ce qu'on chiffre avec.

Oui en effet si on n'ajoute pas la clef au chiffré ou si on ne l'aligne
pas. La seule erreur que je puisse voir est que j'avais aligné la clef
cryptée avec la clef en clair. Une simple petite erreur (oublie de tenir
compte de ce facteur) mais qui peut causer gros problème en ce que ça aide à
calculer les différence entre les caractères de la clef (clair et chiffré)
afin d'aider à trouver la clef en clair elle-même (selon qu'AMcD a trouvé).
Concernant l'algo utilisé, moi-même je n'arrive pas à décrypter les données
cryptées selon que j'ai mentionné sur mon site et selon que j'essayais
d'expliquer dans ce forum en comparaison de numéros de loterie à révéler; je
disais que c'est une impossibilité sans la clef de trouver directement la
clef en clair, mais je ne tenais pas compte du facteur clef intégrée pouvant
donner des différences entre clef en clair et clef chiffrée vu de leur
alignement précis.

Or, la clef se plaçait au début du texte à crypter, donc au début du
texte crypté aussi. En considérant ce fait, on s'aperçoit que c'est grâce à
cet alignement que certaines données de la clef chiffrée pouvaient être
décryptées. L'explication est simple: le rapport de chaque caractère de la
clef dans le chiffré avec celui du caractère de la clef en clair en donnait
des différences en quelque sorte, en sorte que même en changeant de clef les
différences seraient les mêmes à l'exception du dernier caractère de la
clef. Même si la clef était doublée cela ne change rien puisque les
rapports reste les mêmes avec une différence mineur de certaines valeurs, de
1, de 3 et d'une autre valeur pour le dernier caractère. Ajoutez un seul
caractère avant la clef dans le chiffré (sans que ce caractère appartienne à
la clef) et la clef chiffrée n'est plus la même et ne suit plus la logique
que vous utilisez par le soft créé par AMcD puisque la clef chiffrée ne
donne plus de rapport entre deux mêmes caractères de la clef (en clair et
chiffré). Et c'est là que je crois impossible de trouver les données
chiffrés sans la clef car chaque caractère est en rapport aussi (non
seulement cela) avec un autre dans le chiffré avant qu'il soit chiffré, tous
les caractères du chiffré font de même. Le calcul de chaque caractère est en
rapport avec 6 valeurs calculées distinctement.

Donc, ce que j'essais de dire ici est que les différences (près) d'un
caractère de la clef intégrée avec le même caractère de la clef en clair
donnent une valeur pouvant aider assez facilement à trouver son
correspondant (le caractère du clair en rapport avec le même caractère dans
le chiffré donné en double), l'un (caractère de la clef chiffrée) aide à
dénoncer l'autre dans le clair (caractère de la clef en clair) en se servant
des mêmes différences (près) entre les deux. C'est la façon dont je vois
les choses et non nécessairement comme certaine d'entre vous ou comme AMcD.

Mais l'algo en lui-même, personnellement je le trouve sûr si on n'aligne
pas les clefs ou si on ne les intègre pas. J'ai donc enlevé l'option
d'insérer la clef dans la version actuelle (v.2.2.0.2) et ceci règle donc ce
problème.

Donc, lorsque je cite sur mon site que l'algo est de qualité et que mon
but est que ni moi ni personne ne puisse décrypter les données, je dis bien
que c'était mon BUT, et cela est très vrai et n'est pas de la fausse
publicité. La seule erreur a été l'oublie de prendre en compte l'alignement
des deux clefs (chiffrées et claires). Maintenant cette erreur n'est plus
puisque l'option d'insérer la clef n'est plus à partir de la version
2.2.0.2.

Lorsque je parle du nombre à 337 chiffres environ qui constitue la
quantité maximale de possibilités de clefs différentes à essayer, cela est
en rapport avec la case où on écrit ou tape la clef dans AllCrypter, donc
trouver de cette façon la bonne clef; et cette publicité était aussi en
rapport avec un logiciel externe qui pouvait ajouter automatiquement dans
cette case (où on écrit la clef en clair) tous les 256 caractères de la
table (et bien sûr les caractères qui ne sont pas pris en charge ne
s'afficheraient pas mais je suppose que le logiciel tente de tous les
utiliser (les 256); donc encore là je dis vrai et ma publicité n'est pas
trompeuse, y compris les siècles que cela pourrait prendre.

De toute façon à la version 3.0 je veux changer ce TextBox contre un
RichTextBox qui accepte tous les caractères; mais le seul caractère dont
j'ai l'intention de refuser est le caractère ASCII 0 puisqu'il ne ferait que
simplifier les calculs inutilement et pas nécessairement dans le bon sens.

Il a été prouvé, démontré, expliqué, détaillé et argumenté que c'est
faux, que le soft est une passoire, et qu'on ne peut pas honnêtement
laisser qui que ce soit l'utiliser sans le prévenir qu'il ne protège
rien, à peine plus qu'un coup de ROT13 dont il se moque pourtant, tout ça
parce que monsieur ne comprend pas (et ne *veut* pas comprendre) les
bases de la cryptanalyse et croit qu'on peut inventer un algo de
chiffrement qui tient debout dans son coin en 5 minutes alors que
beaucoup de gens nettement plus forts que monsieur s'y sont cassés les
dents. Et je ne parle même pas des gens qui fréquentent ce forum, dont
certains sont pourtant d'un niveau nettement supérieur à la moyenne, sans
parler de leur niveau sur le sujet par rapport au vôtre vu qu'il approche
de l'abysse tellement vous y mettez de la mauvaise volonté.

Donc, oui, heureusement que n'importe qui qui fait une recherche dans
Google sur le soft en question peut trouver les messages qui expliquent
que c'est une passoire et pourquoi c'est une passoire, et pourquoi même en
faisant une version ++ avec deux opérations de plus ce sera toujours une
passoire.

Parmi vous, plusieurs se penche sur les informations données par AMcD le
'professionnel en la matière' et on fait bien quelquefois d'en tenir compte
même si on n'est pas nécessairement d'accord avec tous ses dires puisqu'il a
une certaine expérience qu'il nous partage (tant qu'à moi je suis plutôt
lent à comprendre quelquefois).

Je dis cela parce que lui-même parlait en rapport avec la clef intégrée
aux données cryptées. Mais si on n'intègre pas la clef aux données cryptées
alors son soft et ses codes (de AMcD) sont rendu inutilisables et ne servent
à rien (même s'ils ont servis à démontrer qu'il pouvait décrypter des clefs;
et je le trouve particulièrement doué en la matière vu la rapidité avec
laquelle il flaire ces choses-là). Donc son soft n'est plus d'aucune
utilité à partir de la version 2.2.0.2 qui ne donne plus l'option d'intégrer
une clef au sein du cryptogramme. Son utilité a cependant été auparavant
pour démontrer qu'une clef pouvait être décrypté même si son code était
limité dans le choix des caractères à ce moment-là.

Alors quand vous dîtes qu'AllCrypter a un algo qui ne tient pas, vous
faites alors fausse route à 100% car vous n'avez pas été capable de le
prouver ni vous ni personne d'autre. La faiblesse qu'AllCrypter avait
(avant la version 2.2.0.2) était à cause de l'intégration de la clef de la
façon qu'elle l'était. C'est seulement de cela qu'il s'agissait et non dans
les calculs de l'algorithme lui-même pour crypter les autres données.

AMcD lui-même le dit dans son dernier message que j'ai lu dans ce forum
après les nombreux autres messages écrit sur le sujet. Voici ce qu'il a
écrit dans son dernier message lu (j'ai fait ici un copier/coller' de ce
qu'il a écrit):

**********

[1] Bien qu'ici, ce ne soit pas la partie cryptographique proprement dite
qui soit faible, mais plutôt le concept de stocker une clé facilement
inversible. ...

**********

Si j'ai bien compris la conversation, voici ce que Sylvain a écris
concernant la tentative de décryptage via les codes d'AMcD (mais sans
l'intégration de la clef dans le chiffré d'AllCrypter ) :

*************

on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !
*************

Le cryptage se fait désormais sans la possibilité d'intégrer la clef,
mais j'ai l'intention dans la version 3.0 de donner la possibilité à
l'utilisateur d'intégrer un code d'indentification qui peut indiquer si ce
n'est pas la bonne clef qui est utilisée, bien que ce code n'est pas la clef
elle-même; donc pas de possibilité de réversion dans le calcul pour trouver
la clef. J'ai l'intention de laisser la même base de l'algo mais rajouter
un élément de plus tant qu'à faire une modification pour le code
d'identification.
Voici pour mes quelques constatations concernant la faiblesse de
l'intégration de la clef dans les versions jusqu'à la 2.2.0.1 , faiblesse
démontrée grâce aux codes d'AMcD.

J'écris ceci dans un esprit de bonne volonté.

Bonne journée :)

r.h.

Et non, personne ne dénigre. On ne fait qu'exposer des faits, même si ça
ne vous plaît pas.

Donc il faut reprendre son ego, le remettre dans sa poche, et aller
potasser quelques bouquins sur la cryptanalyse et la cryptographie pour
comprendre qu'au lieu de réinventer une roue qui ne tourne pas (ben oui,
les roues octogonales c'est pas terrible, et c'est pas en essayant de les
cacher qu'elles roulent mieux), il aurait mieux valu utiliser un algo de
chiffrement déjà existant, public, décortiqué, testé et éprouvé, dont les
implémentations libres ne manquent pas. Et bien comprendre en lisant les
références sur le sujet qu'il ne faut pas non plus faire n'importe quoi
avec l'algo en question, l'expérience ayant montré à de nombreuses
reprises qu'on peu prendre un algo sûr et le rendre totalement pas sûr du
tout en 2 temps et 3 mouvements (je citerai juste le cas le plus connu,
WEP...). Genre on évitera de faire un chiffrement AES en mettant la clef
au début du fichier, ce serait quand même pas très futé.

Et pas la peine de revenir pleurer ici que soi disant personne n'a rien
prouvé et qu'on vous en veut et que whatever is là haut n'en pense pas
moins: on s'en moque, on s'en fout, ta gueule, y'en a marre. Plus un mot!

Ah non mais.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opsipwvxa7zscttn@news.free.fr...

Bon,

Il a pas bientôt fini le monsieur? Le monsieur il prétend que son soft est
un outil de chiffrement de "haute qualité" que personne même pas lui il
peut déchiffrer ce qu'on chiffre avec.

Oui en effet si on n'ajoute pas la clef au chiffré ou si on ne l'aligne
pas. La seule erreur que je puisse voir est que j'avais aligné la clef
cryptée avec la clef en clair. Une simple petite erreur (oublie de tenir
compte de ce facteur) mais qui peut causer gros problème en ce que ça aide à
calculer les différence entre les caractères de la clef (clair et chiffré)
afin d'aider à trouver la clef en clair elle-même (selon qu'AMcD a trouvé).
Concernant l'algo utilisé, moi-même je n'arrive pas à décrypter les données
cryptées selon que j'ai mentionné sur mon site et selon que j'essayais
d'expliquer dans ce forum en comparaison de numéros de loterie à révéler; je
disais que c'est une impossibilité sans la clef de trouver directement la
clef en clair, mais je ne tenais pas compte du facteur clef intégrée pouvant
donner des différences entre clef en clair et clef chiffrée vu de leur
alignement précis.

Or, la clef se plaçait au début du texte à crypter, donc au début du
texte crypté aussi. En considérant ce fait, on s'aperçoit que c'est grâce à
cet alignement que certaines données de la clef chiffrée pouvaient être
décryptées. L'explication est simple: le rapport de chaque caractère de la
clef dans le chiffré avec celui du caractère de la clef en clair en donnait
des différences en quelque sorte, en sorte que même en changeant de clef les
différences seraient les mêmes à l'exception du dernier caractère de la
clef. Même si la clef était doublée cela ne change rien puisque les
rapports reste les mêmes avec une différence mineur de certaines valeurs, de
1, de 3 et d'une autre valeur pour le dernier caractère. Ajoutez un seul
caractère avant la clef dans le chiffré (sans que ce caractère appartienne à
la clef) et la clef chiffrée n'est plus la même et ne suit plus la logique
que vous utilisez par le soft créé par AMcD puisque la clef chiffrée ne
donne plus de rapport entre deux mêmes caractères de la clef (en clair et
chiffré). Et c'est là que je crois impossible de trouver les données
chiffrés sans la clef car chaque caractère est en rapport aussi (non
seulement cela) avec un autre dans le chiffré avant qu'il soit chiffré, tous
les caractères du chiffré font de même. Le calcul de chaque caractère est en
rapport avec 6 valeurs calculées distinctement.

Donc, ce que j'essais de dire ici est que les différences (près) d'un
caractère de la clef intégrée avec le même caractère de la clef en clair
donnent une valeur pouvant aider assez facilement à trouver son
correspondant (le caractère du clair en rapport avec le même caractère dans
le chiffré donné en double), l'un (caractère de la clef chiffrée) aide à
dénoncer l'autre dans le clair (caractère de la clef en clair) en se servant
des mêmes différences (près) entre les deux. C'est la façon dont je vois
les choses et non nécessairement comme certaine d'entre vous ou comme AMcD.

Mais l'algo en lui-même, personnellement je le trouve sûr si on n'aligne
pas les clefs ou si on ne les intègre pas. J'ai donc enlevé l'option
d'insérer la clef dans la version actuelle (v.2.2.0.2) et ceci règle donc ce
problème.

Donc, lorsque je cite sur mon site que l'algo est de qualité et que mon
but est que ni moi ni personne ne puisse décrypter les données, je dis bien
que c'était mon BUT, et cela est très vrai et n'est pas de la fausse
publicité. La seule erreur a été l'oublie de prendre en compte l'alignement
des deux clefs (chiffrées et claires). Maintenant cette erreur n'est plus
puisque l'option d'insérer la clef n'est plus à partir de la version
2.2.0.2.

Lorsque je parle du nombre à 337 chiffres environ qui constitue la
quantité maximale de possibilités de clefs différentes à essayer, cela est
en rapport avec la case où on écrit ou tape la clef dans AllCrypter, donc
trouver de cette façon la bonne clef; et cette publicité était aussi en
rapport avec un logiciel externe qui pouvait ajouter automatiquement dans
cette case (où on écrit la clef en clair) tous les 256 caractères de la
table (et bien sûr les caractères qui ne sont pas pris en charge ne
s'afficheraient pas mais je suppose que le logiciel tente de tous les
utiliser (les 256); donc encore là je dis vrai et ma publicité n'est pas
trompeuse, y compris les siècles que cela pourrait prendre.

De toute façon à la version 3.0 je veux changer ce TextBox contre un
RichTextBox qui accepte tous les caractères; mais le seul caractère dont
j'ai l'intention de refuser est le caractère ASCII 0 puisqu'il ne ferait que
simplifier les calculs inutilement et pas nécessairement dans le bon sens.

Il a été prouvé, démontré, expliqué, détaillé et argumenté que c'est
faux, que le soft est une passoire, et qu'on ne peut pas honnêtement
laisser qui que ce soit l'utiliser sans le prévenir qu'il ne protège
rien, à peine plus qu'un coup de ROT13 dont il se moque pourtant, tout ça
parce que monsieur ne comprend pas (et ne *veut* pas comprendre) les
bases de la cryptanalyse et croit qu'on peut inventer un algo de
chiffrement qui tient debout dans son coin en 5 minutes alors que
beaucoup de gens nettement plus forts que monsieur s'y sont cassés les
dents. Et je ne parle même pas des gens qui fréquentent ce forum, dont
certains sont pourtant d'un niveau nettement supérieur à la moyenne, sans
parler de leur niveau sur le sujet par rapport au vôtre vu qu'il approche
de l'abysse tellement vous y mettez de la mauvaise volonté.

Donc, oui, heureusement que n'importe qui qui fait une recherche dans
Google sur le soft en question peut trouver les messages qui expliquent
que c'est une passoire et pourquoi c'est une passoire, et pourquoi même en
faisant une version ++ avec deux opérations de plus ce sera toujours une
passoire.

Parmi vous, plusieurs se penche sur les informations données par AMcD le
'professionnel en la matière' et on fait bien quelquefois d'en tenir compte
même si on n'est pas nécessairement d'accord avec tous ses dires puisqu'il a
une certaine expérience qu'il nous partage (tant qu'à moi je suis plutôt
lent à comprendre quelquefois).

Je dis cela parce que lui-même parlait en rapport avec la clef intégrée
aux données cryptées. Mais si on n'intègre pas la clef aux données cryptées
alors son soft et ses codes (de AMcD) sont rendu inutilisables et ne servent
à rien (même s'ils ont servis à démontrer qu'il pouvait décrypter des clefs;
et je le trouve particulièrement doué en la matière vu la rapidité avec
laquelle il flaire ces choses-là). Donc son soft n'est plus d'aucune
utilité à partir de la version 2.2.0.2 qui ne donne plus l'option d'intégrer
une clef au sein du cryptogramme. Son utilité a cependant été auparavant
pour démontrer qu'une clef pouvait être décrypté même si son code était
limité dans le choix des caractères à ce moment-là.

Alors quand vous dîtes qu'AllCrypter a un algo qui ne tient pas, vous
faites alors fausse route à 100% car vous n'avez pas été capable de le
prouver ni vous ni personne d'autre. La faiblesse qu'AllCrypter avait
(avant la version 2.2.0.2) était à cause de l'intégration de la clef de la
façon qu'elle l'était. C'est seulement de cela qu'il s'agissait et non dans
les calculs de l'algorithme lui-même pour crypter les autres données.

AMcD lui-même le dit dans son dernier message que j'ai lu dans ce forum
après les nombreux autres messages écrit sur le sujet. Voici ce qu'il a
écrit dans son dernier message lu (j'ai fait ici un copier/coller' de ce
qu'il a écrit):

**********

[1] Bien qu'ici, ce ne soit pas la partie cryptographique proprement dite
qui soit faible, mais plutôt le concept de stocker une clé facilement
inversible. ...

**********

Si j'ai bien compris la conversation, voici ce que Sylvain a écris
concernant la tentative de décryptage via les codes d'AMcD (mais sans
l'intégration de la clef dans le chiffré d'AllCrypter ) :

*************

on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !
*************

Le cryptage se fait désormais sans la possibilité d'intégrer la clef,
mais j'ai l'intention dans la version 3.0 de donner la possibilité à
l'utilisateur d'intégrer un code d'indentification qui peut indiquer si ce
n'est pas la bonne clef qui est utilisée, bien que ce code n'est pas la clef
elle-même; donc pas de possibilité de réversion dans le calcul pour trouver
la clef. J'ai l'intention de laisser la même base de l'algo mais rajouter
un élément de plus tant qu'à faire une modification pour le code
d'identification.
Voici pour mes quelques constatations concernant la faiblesse de
l'intégration de la clef dans les versions jusqu'à la 2.2.0.1 , faiblesse
démontrée grâce aux codes d'AMcD.

J'écris ceci dans un esprit de bonne volonté.

Bonne journée :)

r.h.

Et non, personne ne dénigre. On ne fait qu'exposer des faits, même si ça
ne vous plaît pas.

Donc il faut reprendre son ego, le remettre dans sa poche, et aller
potasser quelques bouquins sur la cryptanalyse et la cryptographie pour
comprendre qu'au lieu de réinventer une roue qui ne tourne pas (ben oui,
les roues octogonales c'est pas terrible, et c'est pas en essayant de les
cacher qu'elles roulent mieux), il aurait mieux valu utiliser un algo de
chiffrement déjà existant, public, décortiqué, testé et éprouvé, dont les
implémentations libres ne manquent pas. Et bien comprendre en lisant les
références sur le sujet qu'il ne faut pas non plus faire n'importe quoi
avec l'algo en question, l'expérience ayant montré à de nombreuses
reprises qu'on peu prendre un algo sûr et le rendre totalement pas sûr du
tout en 2 temps et 3 mouvements (je citerai juste le cas le plus connu,
WEP...). Genre on évitera de faire un chiffrement AES en mettant la clef
au début du fichier, ce serait quand même pas très futé.

Et pas la peine de revenir pleurer ici que soi disant personne n'a rien
prouvé et qu'on vous en veut et que whatever is là haut n'en pense pas
moins: on s'en moque, on s'en fout, ta gueule, y'en a marre. Plus un mot!

Ah non mais.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Vous avez filtré cet utilisateur ! Consultez son message

"Jacques Caron" a écrit dans le message de news:

Bon,

Il a pas bientôt fini le monsieur? Le monsieur il prétend que son soft est
un outil de chiffrement de "haute qualité" que personne même pas lui il
peut déchiffrer ce qu'on chiffre avec.

Oui en effet si on n'ajoute pas la clef au chiffré ou si on ne l'aligne
pas. La seule erreur que je puisse voir est que j'avais aligné la clef
cryptée avec la clef en clair. Une simple petite erreur (oublie de tenir
compte de ce facteur) mais qui peut causer gros problème en ce que ça aide à
calculer les différence entre les caractères de la clef (clair et chiffré)
afin d'aider à trouver la clef en clair elle-même (selon qu'AMcD a trouvé).
Concernant l'algo utilisé, moi-même je n'arrive pas à décrypter les données
cryptées selon que j'ai mentionné sur mon site et selon que j'essayais
d'expliquer dans ce forum en comparaison de numéros de loterie à révéler; je
disais que c'est une impossibilité sans la clef de trouver directement la
clef en clair, mais je ne tenais pas compte du facteur clef intégrée pouvant
donner des différences entre clef en clair et clef chiffrée vu de leur
alignement précis.

Or, la clef se plaçait au début du texte à crypter, donc au début du
texte crypté aussi. En considérant ce fait, on s'aperçoit que c'est grâce à
cet alignement que certaines données de la clef chiffrée pouvaient être
décryptées. L'explication est simple: le rapport de chaque caractère de la
clef dans le chiffré avec celui du caractère de la clef en clair en donnait
des différences en quelque sorte, en sorte que même en changeant de clef les
différences seraient les mêmes à l'exception du dernier caractère de la
clef. Même si la clef était doublée cela ne change rien puisque les
rapports reste les mêmes avec une différence mineur de certaines valeurs, de
1, de 3 et d'une autre valeur pour le dernier caractère. Ajoutez un seul
caractère avant la clef dans le chiffré (sans que ce caractère appartienne à
la clef) et la clef chiffrée n'est plus la même et ne suit plus la logique
que vous utilisez par le soft créé par AMcD puisque la clef chiffrée ne
donne plus de rapport entre deux mêmes caractères de la clef (en clair et
chiffré). Et c'est là que je crois impossible de trouver les données
chiffrés sans la clef car chaque caractère est en rapport aussi (non
seulement cela) avec un autre dans le chiffré avant qu'il soit chiffré, tous
les caractères du chiffré font de même. Le calcul de chaque caractère est en
rapport avec 6 valeurs calculées distinctement.

Donc, ce que j'essais de dire ici est que les différences (près) d'un
caractère de la clef intégrée avec le même caractère de la clef en clair
donnent une valeur pouvant aider assez facilement à trouver son
correspondant (le caractère du clair en rapport avec le même caractère dans
le chiffré donné en double), l'un (caractère de la clef chiffrée) aide à
dénoncer l'autre dans le clair (caractère de la clef en clair) en se servant
des mêmes différences (près) entre les deux. C'est la façon dont je vois
les choses et non nécessairement comme certaine d'entre vous ou comme AMcD.

Mais l'algo en lui-même, personnellement je le trouve sûr si on n'aligne
pas les clefs ou si on ne les intègre pas. J'ai donc enlevé l'option
d'insérer la clef dans la version actuelle (v.2.2.0.2) et ceci règle donc ce
problème.

Donc, lorsque je cite sur mon site que l'algo est de qualité et que mon
but est que ni moi ni personne ne puisse décrypter les données, je dis bien
que c'était mon BUT, et cela est très vrai et n'est pas de la fausse
publicité. La seule erreur a été l'oublie de prendre en compte l'alignement
des deux clefs (chiffrées et claires). Maintenant cette erreur n'est plus
puisque l'option d'insérer la clef n'est plus à partir de la version
2.2.0.2.

Lorsque je parle du nombre à 337 chiffres environ qui constitue la
quantité maximale de possibilités de clefs différentes à essayer, cela est
en rapport avec la case où on écrit ou tape la clef dans AllCrypter, donc
trouver de cette façon la bonne clef; et cette publicité était aussi en
rapport avec un logiciel externe qui pouvait ajouter automatiquement dans
cette case (où on écrit la clef en clair) tous les 256 caractères de la
table (et bien sûr les caractères qui ne sont pas pris en charge ne
s'afficheraient pas mais je suppose que le logiciel tente de tous les
utiliser (les 256); donc encore là je dis vrai et ma publicité n'est pas
trompeuse, y compris les siècles que cela pourrait prendre.

De toute façon à la version 3.0 je veux changer ce TextBox contre un
RichTextBox qui accepte tous les caractères; mais le seul caractère dont
j'ai l'intention de refuser est le caractère ASCII 0 puisqu'il ne ferait que
simplifier les calculs inutilement et pas nécessairement dans le bon sens.

Il a été prouvé, démontré, expliqué, détaillé et argumenté que c'est
faux, que le soft est une passoire, et qu'on ne peut pas honnêtement
laisser qui que ce soit l'utiliser sans le prévenir qu'il ne protège
rien, à peine plus qu'un coup de ROT13 dont il se moque pourtant, tout ça
parce que monsieur ne comprend pas (et ne *veut* pas comprendre) les
bases de la cryptanalyse et croit qu'on peut inventer un algo de
chiffrement qui tient debout dans son coin en 5 minutes alors que
beaucoup de gens nettement plus forts que monsieur s'y sont cassés les
dents. Et je ne parle même pas des gens qui fréquentent ce forum, dont
certains sont pourtant d'un niveau nettement supérieur à la moyenne, sans
parler de leur niveau sur le sujet par rapport au vôtre vu qu'il approche
de l'abysse tellement vous y mettez de la mauvaise volonté.

Donc, oui, heureusement que n'importe qui qui fait une recherche dans
Google sur le soft en question peut trouver les messages qui expliquent
que c'est une passoire et pourquoi c'est une passoire, et pourquoi même en
faisant une version ++ avec deux opérations de plus ce sera toujours une
passoire.

Parmi vous, plusieurs se penche sur les informations données par AMcD le
'professionnel en la matière' et on fait bien quelquefois d'en tenir compte
même si on n'est pas nécessairement d'accord avec tous ses dires puisqu'il a
une certaine expérience qu'il nous partage (tant qu'à moi je suis plutôt
lent à comprendre quelquefois).

Je dis cela parce que lui-même parlait en rapport avec la clef intégrée
aux données cryptées. Mais si on n'intègre pas la clef aux données cryptées
alors son soft et ses codes (de AMcD) sont rendu inutilisables et ne servent
à rien (même s'ils ont servis à démontrer qu'il pouvait décrypter des clefs;
et je le trouve particulièrement doué en la matière vu la rapidité avec
laquelle il flaire ces choses-là). Donc son soft n'est plus d'aucune
utilité à partir de la version 2.2.0.2 qui ne donne plus l'option d'intégrer
une clef au sein du cryptogramme. Son utilité a cependant été auparavant
pour démontrer qu'une clef pouvait être décrypté même si son code était
limité dans le choix des caractères à ce moment-là.

Alors quand vous dîtes qu'AllCrypter a un algo qui ne tient pas, vous
faites alors fausse route à 100% car vous n'avez pas été capable de le
prouver ni vous ni personne d'autre. La faiblesse qu'AllCrypter avait
(avant la version 2.2.0.2) était à cause de l'intégration de la clef de la
façon qu'elle l'était. C'est seulement de cela qu'il s'agissait et non dans
les calculs de l'algorithme lui-même pour crypter les autres données.

AMcD lui-même le dit dans son dernier message que j'ai lu dans ce forum
après les nombreux autres messages écrit sur le sujet. Voici ce qu'il a
écrit dans son dernier message lu (j'ai fait ici un copier/coller' de ce
qu'il a écrit):

**********

[1] Bien qu'ici, ce ne soit pas la partie cryptographique proprement dite
qui soit faible, mais plutôt le concept de stocker une clé facilement
inversible. ...

**********

Si j'ai bien compris la conversation, voici ce que Sylvain a écris
concernant la tentative de décryptage via les codes d'AMcD (mais sans
l'intégration de la clef dans le chiffré d'AllCrypter ) :

*************

on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !
*************

Le cryptage se fait désormais sans la possibilité d'intégrer la clef,
mais j'ai l'intention dans la version 3.0 de donner la possibilité à
l'utilisateur d'intégrer un code d'indentification qui peut indiquer si ce
n'est pas la bonne clef qui est utilisée, bien que ce code n'est pas la clef
elle-même; donc pas de possibilité de réversion dans le calcul pour trouver
la clef. J'ai l'intention de laisser la même base de l'algo mais rajouter
un élément de plus tant qu'à faire une modification pour le code
d'identification.
Voici pour mes quelques constatations concernant la faiblesse de
l'intégration de la clef dans les versions jusqu'à la 2.2.0.1 , faiblesse
démontrée grâce aux codes d'AMcD.

J'écris ceci dans un esprit de bonne volonté.

Bonne journée :)

r.h.

Et non, personne ne dénigre. On ne fait qu'exposer des faits, même si ça
ne vous plaît pas.

Donc il faut reprendre son ego, le remettre dans sa poche, et aller
potasser quelques bouquins sur la cryptanalyse et la cryptographie pour
comprendre qu'au lieu de réinventer une roue qui ne tourne pas (ben oui,
les roues octogonales c'est pas terrible, et c'est pas en essayant de les
cacher qu'elles roulent mieux), il aurait mieux valu utiliser un algo de
chiffrement déjà existant, public, décortiqué, testé et éprouvé, dont les
implémentations libres ne manquent pas. Et bien comprendre en lisant les
références sur le sujet qu'il ne faut pas non plus faire n'importe quoi
avec l'algo en question, l'expérience ayant montré à de nombreuses
reprises qu'on peu prendre un algo sûr et le rendre totalement pas sûr du
tout en 2 temps et 3 mouvements (je citerai juste le cas le plus connu,
WEP...). Genre on évitera de faire un chiffrement AES en mettant la clef
au début du fichier, ce serait quand même pas très futé.

Et pas la peine de revenir pleurer ici que soi disant personne n'a rien
prouvé et qu'on vous en veut et que whatever is là haut n'en pense pas
moins: on s'en moque, on s'en fout, ta gueule, y'en a marre. Plus un mot!

Ah non mais.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Nicob

10/12/2004 à 09:36

On Fri, 10 Dec 2004 01:28:16 -0500, Raymond H. wrote:

Cher Raymon H., permettez-moi de vous dire que vous êtes réellement
désespérant ...

Mais l'algo en lui-même, personnellement je le trouve sûr si on
n'aligne pas les clefs ou si on ne les intègre pas.

Il y a une semaine, l'ensemble du soft vous semblait sûr. Ceci ne vous
incite donc pas à une plus grande modestie ?

La seule erreur a été l'oublie de prendre en compte l'alignement des
deux clefs (chiffrées et claires).

La seule erreur utilisée par le code d'AMcD ! D'autres vous ont parlé
(entre autres) de l'effet d'avalanche, des redondances constatées dans
le chiffré, des piètres performances, ...

Parmi vous, plusieurs se penche sur les informations données par AMcD
le 'professionnel en la matière'

Vous n'avez aucune idée de ce que vous dites. AMcD n'est nullement un
'pro en la maitière' et ce forum regorge de gens *très* *très* *très*
compétents dans le domaine, mais qui n'ont même pas pris la peine de
répondre à vos messages.

Imaginez dans quel état ils (ces gens très forts) auraient pu mettre
votre logiciel ...

Alors quand vous dîtes qu'AllCrypter a un algo qui ne tient pas,
vous faites alors fausse route à 100% car vous n'avez pas été capable
de le prouver ni vous ni personne d'autre

En crypto, c'est à l'auteur de l'algo de prouver sa solidité, et non pas
à des hobbyistes de casser une boite noire sans interface digne de ce nom
(API ou command-line).

J'ai l'intention de laisser la même base de l'algo mais rajouter un
élément de plus tant qu'à faire une modification pour le code
d'identification.

Rajoutez, rajoutez, ça fera toujours des (L)heureux ...

Nicob

Sylvain

10/12/2004 à 09:43

Si j'ai bien compris la conversation, voici ce que Sylvain a écris
concernant la tentative de décryptage via les codes d'AMcD (mais sans
l'intégration de la clef dans le chiffré d'AllCrypter ) :

*************
on note que "l'auteur" (sic) a, dès les premières remarques postées ici,
libéré une version ne stockant pas cette clé ... et générant des
fichiers non valides (tronqués) lors du déchiffrement !
*************

je ne suis pas certain de votre bonne compréhension!

mon point était de souligner (ici aussi) votre totale négligence: vous
avez libéré une version *sans le moindre test* et ceci a au final privé
les personnes chiffrant leurs données avec votre soft (en fait p.e.
personne a part vous) de l'accès à ces données.

ce fait n'est rien qu'inexcusable.

Sylvain.

AMcD® : méthode de cryptage.

10 réponses

Veuillez sélectionner un problème