Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le message
de
news: 44d1ddd2$0$690$
[...]Tout d'abord, il génère 3 fois plus de données en sortie qu'en entrée.
Économiquement parlant, c'est une ruine.
oui mais c'est fait expres
Moui. En pratique, c'est Moche (tm). Si ça ne vous pose pas de
problème, on va diviser votre salaire par 3, la taille de votre disque
dur par 3, de votre RAM par 3, de votre appart par 3, etc... Bon. On
évite ces arguments, ça ne sert à rien ici.Ensuite tu ne vérifies pas en sortie que les codes soient compris netre
0
et 255. On voit par exemple un code 309. C'est bien si tu bosses en
ASCII
étendu, mais si tu utilises un autre alphabet...
effectivement mais si ca te pose un probleme , pourtant ca n'en pose
aucun
pour decrypter
Effectivement, en sortie de chiffrement, chaque caractère du clair
peut être transformé en un nombre qui peut avoir pour valeur maxi 344
(%5+89, 89 étant la plus haute valeur admissible par un caractère de
PrivateKey).
-----
$UrlCrypte=sprintf("%s%03d",$UrlCrypte,(ord($URL[$i])+ord($PrivateKey[$indiceCle])));
-----Pour casser ton truc, bof. Comme du Vigénère. Tu "reconstruis" les
codes,
par exemple les 9 caractères 139184200 deviennent les 3 nombres 139,
184
et 200. Ensuite, tu fais une analyse de fréquences sur chaque nombre,
modulo 16 sur son index, puisque ta clé est de 16 caractères.
attention petite confidence la cle calculer tourne donc le A ne sera
jamais
la meme valeur, du moins il peut en prendre 16
comme chaque lettre donc pour l'analyse de frequence c'est pas top
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
-----
$PrivateKey = "";
$indiceCle=1;
$UrlCrypte="";
for ($i=0; $i<strlen($PublicKey); $i++)
$PrivateKey > sprintf("%s%s",$PrivateKey,chr(fmod((ord($PublicKey[($i)])*101/(($i+1)*9)),25)+65));
-----
A noter qu'avec l'exemple ci-dessus, la lettre 'Z' ne peut pas
apparaître dans PrivateKey, vous effectuez une opération modulo 25,
qui vous donnera donc (après conversion flottant->entier) à une valeur
comprise entre 0 et 24 inclus, ce qui laisse de côté la dernière
lettre de l'alphabet.
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
si c bien le k
-+-YT in GNU: mon clavier est kc -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le message
de
news: 44d1ddd2$0$690$
[...]Tout d'abord, il génère 3 fois plus de données en sortie qu'en entrée.
Économiquement parlant, c'est une ruine.
oui mais c'est fait expres
Moui. En pratique, c'est Moche (tm). Si ça ne vous pose pas de
problème, on va diviser votre salaire par 3, la taille de votre disque
dur par 3, de votre RAM par 3, de votre appart par 3, etc... Bon. On
évite ces arguments, ça ne sert à rien ici.Ensuite tu ne vérifies pas en sortie que les codes soient compris netre
0
et 255. On voit par exemple un code 309. C'est bien si tu bosses en
ASCII
étendu, mais si tu utilises un autre alphabet...
effectivement mais si ca te pose un probleme , pourtant ca n'en pose
aucun
pour decrypter
Effectivement, en sortie de chiffrement, chaque caractère du clair
peut être transformé en un nombre qui peut avoir pour valeur maxi 344
(%5+89, 89 étant la plus haute valeur admissible par un caractère de
PrivateKey).
-----
$UrlCrypte=sprintf("%s%03d",$UrlCrypte,(ord($URL[$i])+ord($PrivateKey[$indiceCle])));
-----Pour casser ton truc, bof. Comme du Vigénère. Tu "reconstruis" les
codes,
par exemple les 9 caractères 139184200 deviennent les 3 nombres 139,
184
et 200. Ensuite, tu fais une analyse de fréquences sur chaque nombre,
modulo 16 sur son index, puisque ta clé est de 16 caractères.
attention petite confidence la cle calculer tourne donc le A ne sera
jamais
la meme valeur, du moins il peut en prendre 16
comme chaque lettre donc pour l'analyse de frequence c'est pas top
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
-----
$PrivateKey = "";
$indiceCle=1;
$UrlCrypte="";
for ($i=0; $i<strlen($PublicKey); $i++)
$PrivateKey > sprintf("%s%s",$PrivateKey,chr(fmod((ord($PublicKey[($i)])*101/(($i+1)*9)),25)+65));
-----
A noter qu'avec l'exemple ci-dessus, la lettre 'Z' ne peut pas
apparaître dans PrivateKey, vous effectuez une opération modulo 25,
qui vous donnera donc (après conversion flottant->entier) à une valeur
comprise entre 0 et 24 inclus, ce qui laisse de côté la dernière
lettre de l'alphabet.
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
si c bien le k
-+-YT in GNU: mon clavier est kc -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:
"Arnold McDonald (AMcD)" <killspammers@free.fr> a écrit dans le message
de
news: 44d1ddd2$0$690$626a54ce@news.free.fr...
[...]
Tout d'abord, il génère 3 fois plus de données en sortie qu'en entrée.
Économiquement parlant, c'est une ruine.
oui mais c'est fait expres
Moui. En pratique, c'est Moche (tm). Si ça ne vous pose pas de
problème, on va diviser votre salaire par 3, la taille de votre disque
dur par 3, de votre RAM par 3, de votre appart par 3, etc... Bon. On
évite ces arguments, ça ne sert à rien ici.
Ensuite tu ne vérifies pas en sortie que les codes soient compris netre
0
et 255. On voit par exemple un code 309. C'est bien si tu bosses en
ASCII
étendu, mais si tu utilises un autre alphabet...
effectivement mais si ca te pose un probleme , pourtant ca n'en pose
aucun
pour decrypter
Effectivement, en sortie de chiffrement, chaque caractère du clair
peut être transformé en un nombre qui peut avoir pour valeur maxi 344
(%5+89, 89 étant la plus haute valeur admissible par un caractère de
PrivateKey).
-----
$UrlCrypte=sprintf("%s%03d",$UrlCrypte,(ord($URL[$i])+ord($PrivateKey[$indiceCle])));
-----
Pour casser ton truc, bof. Comme du Vigénère. Tu "reconstruis" les
codes,
par exemple les 9 caractères 139184200 deviennent les 3 nombres 139,
184
et 200. Ensuite, tu fais une analyse de fréquences sur chaque nombre,
modulo 16 sur son index, puisque ta clé est de 16 caractères.
attention petite confidence la cle calculer tourne donc le A ne sera
jamais
la meme valeur, du moins il peut en prendre 16
comme chaque lettre donc pour l'analyse de frequence c'est pas top
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
-----
$PrivateKey = "";
$indiceCle=1;
$UrlCrypte="";
for ($i=0; $i<strlen($PublicKey); $i++)
$PrivateKey > sprintf("%s%s",$PrivateKey,chr(fmod((ord($PublicKey[($i)])*101/(($i+1)*9)),25)+65));
-----
A noter qu'avec l'exemple ci-dessus, la lettre 'Z' ne peut pas
apparaître dans PrivateKey, vous effectuez une opération modulo 25,
qui vous donnera donc (après conversion flottant->entier) à une valeur
comprise entre 0 et 24 inclus, ce qui laisse de côté la dernière
lettre de l'alphabet.
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
si c bien le k
-+-YT in GNU: mon clavier est kc -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:
"Arnold McDonald (AMcD)" <killspammers@free.fr> a écrit dans le message
de
news: 44d1ddd2$0$690$626a54ce@news.free.fr...
[...]
Tout d'abord, il génère 3 fois plus de données en sortie qu'en entrée.
Économiquement parlant, c'est une ruine.
oui mais c'est fait expres
Moui. En pratique, c'est Moche (tm). Si ça ne vous pose pas de
problème, on va diviser votre salaire par 3, la taille de votre disque
dur par 3, de votre RAM par 3, de votre appart par 3, etc... Bon. On
évite ces arguments, ça ne sert à rien ici.
Ensuite tu ne vérifies pas en sortie que les codes soient compris netre
0
et 255. On voit par exemple un code 309. C'est bien si tu bosses en
ASCII
étendu, mais si tu utilises un autre alphabet...
effectivement mais si ca te pose un probleme , pourtant ca n'en pose
aucun
pour decrypter
Effectivement, en sortie de chiffrement, chaque caractère du clair
peut être transformé en un nombre qui peut avoir pour valeur maxi 344
(%5+89, 89 étant la plus haute valeur admissible par un caractère de
PrivateKey).
-----
$UrlCrypte=sprintf("%s%03d",$UrlCrypte,(ord($URL[$i])+ord($PrivateKey[$indiceCle])));
-----
Pour casser ton truc, bof. Comme du Vigénère. Tu "reconstruis" les
codes,
par exemple les 9 caractères 139184200 deviennent les 3 nombres 139,
184
et 200. Ensuite, tu fais une analyse de fréquences sur chaque nombre,
modulo 16 sur son index, puisque ta clé est de 16 caractères.
attention petite confidence la cle calculer tourne donc le A ne sera
jamais
la meme valeur, du moins il peut en prendre 16
comme chaque lettre donc pour l'analyse de frequence c'est pas top
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
-----
$PrivateKey = "";
$indiceCle=1;
$UrlCrypte="";
for ($i=0; $i<strlen($PublicKey); $i++)
$PrivateKey > sprintf("%s%s",$PrivateKey,chr(fmod((ord($PublicKey[($i)])*101/(($i+1)*9)),25)+65));
-----
A noter qu'avec l'exemple ci-dessus, la lettre 'Z' ne peut pas
apparaître dans PrivateKey, vous effectuez une opération modulo 25,
qui vous donnera donc (après conversion flottant->entier) à une valeur
comprise entre 0 et 24 inclus, ce qui laisse de côté la dernière
lettre de l'alphabet.
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
si c bien le k
-+-YT in GNU: mon clavier est kc -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le message
de
news: 44d1ddd2$0$690$
[...]Tout d'abord, il génère 3 fois plus de données en sortie qu'en entrée.
Économiquement parlant, c'est une ruine.
oui mais c'est fait expres
Moui. En pratique, c'est Moche (tm). Si ça ne vous pose pas de
problème, on va diviser votre salaire par 3, la taille de votre disque
dur par 3, de votre RAM par 3, de votre appart par 3, etc... Bon. On
évite ces arguments, ça ne sert à rien ici.Ensuite tu ne vérifies pas en sortie que les codes soient compris netre
0
et 255. On voit par exemple un code 309. C'est bien si tu bosses en
ASCII
étendu, mais si tu utilises un autre alphabet...
effectivement mais si ca te pose un probleme , pourtant ca n'en pose
aucun
pour decrypter
Effectivement, en sortie de chiffrement, chaque caractère du clair
peut être transformé en un nombre qui peut avoir pour valeur maxi 344
(%5+89, 89 étant la plus haute valeur admissible par un caractère de
PrivateKey).
-----
$UrlCrypte=sprintf("%s%03d",$UrlCrypte,(ord($URL[$i])+ord($PrivateKey[$indiceCle])));
-----Pour casser ton truc, bof. Comme du Vigénère. Tu "reconstruis" les
codes,
par exemple les 9 caractères 139184200 deviennent les 3 nombres 139,
184
et 200. Ensuite, tu fais une analyse de fréquences sur chaque nombre,
modulo 16 sur son index, puisque ta clé est de 16 caractères.
attention petite confidence la cle calculer tourne donc le A ne sera
jamais
la meme valeur, du moins il peut en prendre 16
comme chaque lettre donc pour l'analyse de frequence c'est pas top
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
-----
$PrivateKey = "";
$indiceCle=1;
$UrlCrypte="";
for ($i=0; $i<strlen($PublicKey); $i++)
$PrivateKey > sprintf("%s%s",$PrivateKey,chr(fmod((ord($PublicKey[($i)])*101/(($i+1)*9)),25)+65));
-----
A noter qu'avec l'exemple ci-dessus, la lettre 'Z' ne peut pas
apparaître dans PrivateKey, vous effectuez une opération modulo 25,
qui vous donnera donc (après conversion flottant->entier) à une valeur
comprise entre 0 et 24 inclus, ce qui laisse de côté la dernière
lettre de l'alphabet.
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
si c bien le k
-+-YT in GNU: mon clavier est kc -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le message
de
news: 44d1ddd2$0$690$
[...]Tout d'abord, il génère 3 fois plus de données en sortie qu'en entrée.
Économiquement parlant, c'est une ruine.
oui mais c'est fait expres
Moui. En pratique, c'est Moche (tm). Si ça ne vous pose pas de
problème, on va diviser votre salaire par 3, la taille de votre disque
dur par 3, de votre RAM par 3, de votre appart par 3, etc... Bon. On
évite ces arguments, ça ne sert à rien ici.Ensuite tu ne vérifies pas en sortie que les codes soient compris netre
0
et 255. On voit par exemple un code 309. C'est bien si tu bosses en
ASCII
étendu, mais si tu utilises un autre alphabet...
effectivement mais si ca te pose un probleme , pourtant ca n'en pose
aucun
pour decrypter
Effectivement, en sortie de chiffrement, chaque caractère du clair
peut être transformé en un nombre qui peut avoir pour valeur maxi 344
(%5+89, 89 étant la plus haute valeur admissible par un caractère de
PrivateKey).
-----
$UrlCrypte=sprintf("%s%03d",$UrlCrypte,(ord($URL[$i])+ord($PrivateKey[$indiceCle])));
-----Pour casser ton truc, bof. Comme du Vigénère. Tu "reconstruis" les
codes,
par exemple les 9 caractères 139184200 deviennent les 3 nombres 139,
184
et 200. Ensuite, tu fais une analyse de fréquences sur chaque nombre,
modulo 16 sur son index, puisque ta clé est de 16 caractères.
attention petite confidence la cle calculer tourne donc le A ne sera
jamais
la meme valeur, du moins il peut en prendre 16
comme chaque lettre donc pour l'analyse de frequence c'est pas top
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
-----
$PrivateKey = "";
$indiceCle=1;
$UrlCrypte="";
for ($i=0; $i<strlen($PublicKey); $i++)
$PrivateKey > sprintf("%s%s",$PrivateKey,chr(fmod((ord($PublicKey[($i)])*101/(($i+1)*9)),25)+65));
-----
A noter qu'avec l'exemple ci-dessus, la lettre 'Z' ne peut pas
apparaître dans PrivateKey, vous effectuez une opération modulo 25,
qui vous donnera donc (après conversion flottant->entier) à une valeur
comprise entre 0 et 24 inclus, ce qui laisse de côté la dernière
lettre de l'alphabet.
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
si c bien le k
-+-YT in GNU: mon clavier est kc -+-
"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le message
de
news: 44d1ddd2$0$690$
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
non le texte est un article tout ce qu'il y a d'officiel sur une base de
données
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
avec les remarque de arnold maintenant ca en a puisque je j'utilise
le couple cle publique cle privée
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
ou pour la private je voulais lilite a 26 caractere possible. mais dependant
d'autre chose
la cle publique.
maintenant que j'ai mis le couple est plus compliqué ? ou
plus long a trouve?
Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
20060803142548.GB5500@seclogd.org...
Hodie III Non. Aug. MMVI est, Firetox scripsit:
"Arnold McDonald (AMcD)" <killspammers@free.fr> a écrit dans le message
de
news: 44d1ddd2$0$690$626a54ce@news.free.fr...
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
non le texte est un article tout ce qu'il y a d'officiel sur une base de
données
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
avec les remarque de arnold maintenant ca en a puisque je j'utilise
le couple cle publique cle privée
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
ou pour la private je voulais lilite a 26 caractere possible. mais dependant
d'autre chose
la cle publique.
maintenant que j'ai mis le couple est plus compliqué ? ou
plus long a trouve?
Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : gxxxx@club-internet.fr Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le message
de
news: 44d1ddd2$0$690$
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
non le texte est un article tout ce qu'il y a d'officiel sur une base de
données
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
avec les remarque de arnold maintenant ca en a puisque je j'utilise
le couple cle publique cle privée
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
ou pour la private je voulais lilite a 26 caractere possible. mais dependant
d'autre chose
la cle publique.
maintenant que j'ai mis le couple est plus compliqué ? ou
plus long a trouve?
Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le
message
de
news: 44d1ddd2$0$690$
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
[...]Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
non le texte est un article tout ce qu'il y a d'officiel sur une base de
données
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
avec les remarque de arnold maintenant ca en a puisque je j'utilise
le couple cle publique cle privée
Ca dépend comment vous l'utilisez, je n'ai rien vu de vous à ce sujet.
Et si possible, évitez les termes clé publique/clé privée, ça fait
référence à tout autre chose que ce que vous produisez ici. Dans votre
code, vous avez un mot de passe (PublicKey), et une clé dérivée
(PrivateKey).
oki
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
ou pour la private je voulais lilite a 26 caractere possible. mais
dependant
d'autre chose
la cle publique.
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.maintenant que j'ai mis le couple est plus compliqué ? ou
plus long a trouve?
Ben... Sans plus d'infos sur le comment vous avez fait le machin,
difficile de donner un avis...
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
20060803142548.GB5500@seclogd.org...
Hodie III Non. Aug. MMVI est, Firetox scripsit:
"Arnold McDonald (AMcD)" <killspammers@free.fr> a écrit dans le
message
de
news: 44d1ddd2$0$690$626a54ce@news.free.fr...
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
[...]
Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
non le texte est un article tout ce qu'il y a d'officiel sur une base de
données
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
avec les remarque de arnold maintenant ca en a puisque je j'utilise
le couple cle publique cle privée
Ca dépend comment vous l'utilisez, je n'ai rien vu de vous à ce sujet.
Et si possible, évitez les termes clé publique/clé privée, ça fait
référence à tout autre chose que ce que vous produisez ici. Dans votre
code, vous avez un mot de passe (PublicKey), et une clé dérivée
(PrivateKey).
oki
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
ou pour la private je voulais lilite a 26 caractere possible. mais
dependant
d'autre chose
la cle publique.
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
maintenant que j'ai mis le couple est plus compliqué ? ou
plus long a trouve?
Ben... Sans plus d'infos sur le comment vous avez fait le machin,
difficile de donner un avis...
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : gxxxx@club-internet.fr Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:"Arnold McDonald (AMcD)" a écrit dans le
message
de
news: 44d1ddd2$0$690$
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
[...]Ben oui, c'est du Vigenère, avec une clé de 16 caractères de long, à
ceci près que vous ne faites pas l'opération (modulo 255) habituelle,
ce qui ne change rien, l'attaquant peut la faire et retomber sur
quelque chose de plus "classique". Les caractères du clair de rang 1,
17, 33, ... seront chiffrés par le premier caractère de PrivateKey;
ceux de rang 2, 18, 34, ... seront chiffrés par le deuxième caractère
de PrivateKey, etc... On sait que la clé fait 16 caractères de long,
on prépare donc 16 (petites) listes, et on effectue une analyse de
fréquence sur chacune de ces petites listes. Le texte est de vous? (en
gros, est-ce qu'il y a les fautes avec?)
non le texte est un article tout ce qu'il y a d'officiel sur une base de
données
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
Dans votre algo/code source, je ne comprend pas l'utilité de
transformer votre PublicKey en PrivateKey. Ca n'ajoute rien en terme
de sécurité, l'attaquant cherchera à trouver la clé ayant
effectivement chiffré le texte, en l'occurrence PrivateKey:
avec les remarque de arnold maintenant ca en a puisque je j'utilise
le couple cle publique cle privée
Ca dépend comment vous l'utilisez, je n'ai rien vu de vous à ce sujet.
Et si possible, évitez les termes clé publique/clé privée, ça fait
référence à tout autre chose que ce que vous produisez ici. Dans votre
code, vous avez un mot de passe (PublicKey), et une clé dérivée
(PrivateKey).
oki
Votre méthode de conversion PublicKey->PrivateKey introduis un biais
statistique.
Par exemple, le caractère 'C' dans PublicKey aura 37.5% de chances
d'être transformé en 'A', 12.5% de chances d'être transformé en 'H',
'M', ou 'S', et 6.25% de chances d'être transformé en 'B', 'D', 'I',
ou 'V', au lieu de 6.25% de chances d'être transformé en 1 lettre
parmi 16.
De même, en testant tous les caractères parmi l'ensemble {0-9, A-Z,
a-z}, on remarque que certaines positions dans PrivateKey ont leurs
préférences. Par exemple, le 13ème caractère de PrivateKey a 24% de
chances d'être un 'T', 16% de chances d'être un 'N', 12% de chances
d'être parmi {A, B, Q, R, S, U, V, W, X, Y}, etc. Une répartition
équiprobable aurait donné 4% de chances aux 25 lettres possibles.
ou pour la private je voulais lilite a 26 caractere possible. mais
dependant
d'autre chose
la cle publique.
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.maintenant que j'ai mis le couple est plus compliqué ? ou
plus long a trouve?
Ben... Sans plus d'infos sur le comment vous avez fait le machin,
difficile de donner un avis...
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----Nous recherchons une streap-teaseuse confirmée pour animer des dîners
dansants en région parisienne. Cette offre est sérieuse. Email pour
premier contact : Tél Philippe : 0142458XXX
-+- PG in Guide du Neuneu Usenet - Le premeir contact sera le bon -+-
au moins votre remarque si la cle privee etant issue de plusieurs cle
publiques a ete ameliore
la j'ai appris
maintenant la cryptage se fait sur le couple cle publique+cle privee
donc meme si la cle privee peut etre identique suivant les cle publiques, il
faut le couple
l"ensemble etant maintenant unique
au moins votre remarque si la cle privee etant issue de plusieurs cle
publiques a ete ameliore
la j'ai appris
maintenant la cryptage se fait sur le couple cle publique+cle privee
donc meme si la cle privee peut etre identique suivant les cle publiques, il
faut le couple
l"ensemble etant maintenant unique
au moins votre remarque si la cle privee etant issue de plusieurs cle
publiques a ete ameliore
la j'ai appris
maintenant la cryptage se fait sur le couple cle publique+cle privee
donc meme si la cle privee peut etre identique suivant les cle publiques, il
faut le couple
l"ensemble etant maintenant unique
au moins votre remarque si la cle privee etant issue de plusieurs cle
publiques a ete ameliore
la j'ai appris
maintenant la cryptage se fait sur le couple cle publique+cle privee
donc meme si la cle privee peut etre identique suivant les cle publiques,
il
faut le couple
l"ensemble etant maintenant unique
avec la clé "BAA" et la clé "VAA" j'avais une PrivateKey identique :
"POS". Donc un souci. Maintenant, que tu le retravaille ne change rien.
On ne va pas chercher à trouver PublicKey, mais PrivateKey. Utilise
directement PublicKey... le code sera plus simple et probablement moins
bogué.
Ensuite, il y a des bogues comme on te l'a déjà fait remarquer. Ca
c'est louche comme code. Tu demande à des gens de t'aider et tu
fournis un truc qui ne marche pas... hé ben.
Il y a aussi la remarque d'Arnold : ton clair n'est pas simplement une
suite de lettres de même casse, hein. Sur 1/16ème du chiffre j'ai des
vals asciis variant entre 56 et 216... Ensuite j'ai 52 (2*26)
caractères différents, éparpillés bizarrement.
Donc finalement tu as un Vigenère biaisé et bogué. Bravo. Personne
ne l'avait encore fait. Perso ça m'amuse ce genre de trucs, mais là
c'est vraiment trop. Je lache ça. C'est inutile et tu prends les gens
pour des cons, vraiment.
Alors avant de rebalancer un truc modifié et remodifié en fonction
des remarques qui arrivent,
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous pourrez
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?
(3) essaies de le casser par toi même : c'est formateur
et tu vois les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas specialiste
au moins votre remarque si la cle privee etant issue de plusieurs cle
publiques a ete ameliore
la j'ai appris
maintenant la cryptage se fait sur le couple cle publique+cle privee
donc meme si la cle privee peut etre identique suivant les cle publiques,
il
faut le couple
l"ensemble etant maintenant unique
avec la clé "BAA" et la clé "VAA" j'avais une PrivateKey identique :
"POS". Donc un souci. Maintenant, que tu le retravaille ne change rien.
On ne va pas chercher à trouver PublicKey, mais PrivateKey. Utilise
directement PublicKey... le code sera plus simple et probablement moins
bogué.
Ensuite, il y a des bogues comme on te l'a déjà fait remarquer. Ca
c'est louche comme code. Tu demande à des gens de t'aider et tu
fournis un truc qui ne marche pas... hé ben.
Il y a aussi la remarque d'Arnold : ton clair n'est pas simplement une
suite de lettres de même casse, hein. Sur 1/16ème du chiffre j'ai des
vals asciis variant entre 56 et 216... Ensuite j'ai 52 (2*26)
caractères différents, éparpillés bizarrement.
Donc finalement tu as un Vigenère biaisé et bogué. Bravo. Personne
ne l'avait encore fait. Perso ça m'amuse ce genre de trucs, mais là
c'est vraiment trop. Je lache ça. C'est inutile et tu prends les gens
pour des cons, vraiment.
Alors avant de rebalancer un truc modifié et remodifié en fonction
des remarques qui arrivent,
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous pourrez
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?
(3) essaies de le casser par toi même : c'est formateur
et tu vois les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas specialiste
au moins votre remarque si la cle privee etant issue de plusieurs cle
publiques a ete ameliore
la j'ai appris
maintenant la cryptage se fait sur le couple cle publique+cle privee
donc meme si la cle privee peut etre identique suivant les cle publiques,
il
faut le couple
l"ensemble etant maintenant unique
avec la clé "BAA" et la clé "VAA" j'avais une PrivateKey identique :
"POS". Donc un souci. Maintenant, que tu le retravaille ne change rien.
On ne va pas chercher à trouver PublicKey, mais PrivateKey. Utilise
directement PublicKey... le code sera plus simple et probablement moins
bogué.
Ensuite, il y a des bogues comme on te l'a déjà fait remarquer. Ca
c'est louche comme code. Tu demande à des gens de t'aider et tu
fournis un truc qui ne marche pas... hé ben.
Il y a aussi la remarque d'Arnold : ton clair n'est pas simplement une
suite de lettres de même casse, hein. Sur 1/16ème du chiffre j'ai des
vals asciis variant entre 56 et 216... Ensuite j'ai 52 (2*26)
caractères différents, éparpillés bizarrement.
Donc finalement tu as un Vigenère biaisé et bogué. Bravo. Personne
ne l'avait encore fait. Perso ça m'amuse ce genre de trucs, mais là
c'est vraiment trop. Je lache ça. C'est inutile et tu prends les gens
pour des cons, vraiment.
Alors avant de rebalancer un truc modifié et remodifié en fonction
des remarques qui arrivent,
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous pourrez
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?
(3) essaies de le casser par toi même : c'est formateur
et tu vois les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas specialiste
"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
fonction permettant cela dans dll exterieur
donc suivant le systeme ou l'on install (surtout pour les mobile) il faut
les dll adequates
donc il faut un cryptage assez complexe mais pas trop car sinon on passe
directment en ssl
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
oui un derivé, mais c'est la meme technique
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
j'ai toujours la version origniale. et la nouvelle version
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
20060803145039.GA6868@seclogd.org...
Hodie III Non. Aug. MMVI est, Firetox scripsit:
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
fonction permettant cela dans dll exterieur
donc suivant le systeme ou l'on install (surtout pour les mobile) il faut
les dll adequates
donc il faut un cryptage assez complexe mais pas trop car sinon on passe
directment en ssl
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
oui un derivé, mais c'est la meme technique
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
j'ai toujours la version origniale. et la nouvelle version
"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
fonction permettant cela dans dll exterieur
donc suivant le systeme ou l'on install (surtout pour les mobile) il faut
les dll adequates
donc il faut un cryptage assez complexe mais pas trop car sinon on passe
directment en ssl
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
oui un derivé, mais c'est la meme technique
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
j'ai toujours la version origniale. et la nouvelle version
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
fonction permettant cela dans dll exterieur
Uh? "Google est ton ami" (tm). La conversion de/vers Base64 tient en
quelques lignes, pas besoin de DLL machin bidule truc... Trouvez un
autre argumentaire, le B.S. passe assez mal, ici...
Vous faites du PHP, c'est ça? 5 mn à fouiller sur le site www.php.net
m'ont permi de trouver le manuel en Français, et les fonctions
base64_encode(), base64_decode(). Ca m'aurait étonné qu'un langage
vieux de 10 ans, et qui plus est orienté Web, n'intègre pas cette
fonctionnalité en standard...
oui ca je sais , mais le language qui crypte n'est pas php. php decrypte et
donc suivant le systeme ou l'on install (surtout pour les mobile) il faut
les dll adequates
donc il faut un cryptage assez complexe mais pas trop car sinon on passe
directment en ssl
Attention aux gros mots, l'aiguille du troll-o-mètre grimpe vers le
rouge... Le gap entre un Vigenère et ce qu'on emploie en SSL n'est pas
de ceux qu'on parcours les doigts dans le nez, après avoir regardé un
reportage sur M6 (ou Arte, ça marche aussi).
le logiciel propose 1 cryptage (dont on parle) mais aussi de passer en SSL
[...]"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Donc en Français sans fautes connues de vous... Déjà, savoir que c'est
du Français, c'est bien...Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
oui un derivé, mais c'est la meme technique
Non. Ce que vous fournissez n'est *pas* un Vigenère *dérivé*, c'est un
Vigenère. Point. Que vous fassiez mille transformations de clés ne
change rien, même si au final ce qui chiffre votre texte est une
variable s'appelant $MonTrucEnPlumes, et que vous appelez une "DLL"
codée à partir d'un source en Ruby. Dans la "nouvelle" version (qui
est certainement mieux que l'ancienne; à ce sujet, vous ne voulez
vraiment pas faire de marketing? vous semblez avoir des dispositions),
vous chiffrez avec quelque chose qui est la somme de
PublicKey+PrivateKey, 2 constantes de 16 caractères. La clé effective
est donc une constante de 16 caractères, entièrement déterminés par
PublicKey. C'est un Vigenère.
La "nouvelle version" n'améliore donc pas le système de chiffrement,
qui reste un Vigenère, comme l'ancienne. Les biais statistiques sont
très certainement modifiés, mais je ne sais pas (encore) dans quel
sens. Peu importe, ce sera attaqué comme un Vigenère (au fait, vous
savez que vous avez codé un Vigenère?), et la "clé" trouvée sera la
somme PublicKey+PrivateKey (somme effectuée caractère par caractère,
en prenant la valeur "ASCII" de chaque caractère, sans modulo).
[...]Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Toujours pas de réponse à ce sujet. Vous lisez en diagonale? Ce serait
mesquin de votre part...
le point important dans le dev du logiciel etait que l'utilisateur puisse
[...]Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
j'ai toujours la version origniale. et la nouvelle version
Bien. Le chiffré du nouveau défi a la même taille, j'en conclus qu'il
provient du même clair, j'ai bon? C'est chiffré avec la même
"PublicKey"?
oui exactement je n'ai changer que le script php et la partie du logiciel
S'il vous plait, ajoutez la compétence "je ne quote pas comme un
goret" dans vos bonnes résolutions du mois d'août...
<mode "oh, que je suis méchant">
Non, sérieusement, si j'étais conseiller d'orientation, je vous dirais
qu'avec de telles dispositions, laissez tomber la technique, allez
vers le marketing. Ou postulez chez Accenture, au choix <g>...
</mode "oh, que je suis méchant">
ca depend de notre specialite et la crypto n'est pas la mienne.
Bon... Je bosse quand, moi? Hein?
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Pour les reponses privees, j'aurais pu ajouter mon adresse dans
un reply block crypte avec pgp et demander de le poster
à
-+- A in GNU - En revanche, me présenter c'est un peu dur. -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
20060803145039.GA6868@seclogd.org...
Hodie III Non. Aug. MMVI est, Firetox scripsit:
[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
fonction permettant cela dans dll exterieur
Uh? "Google est ton ami" (tm). La conversion de/vers Base64 tient en
quelques lignes, pas besoin de DLL machin bidule truc... Trouvez un
autre argumentaire, le B.S. passe assez mal, ici...
Vous faites du PHP, c'est ça? 5 mn à fouiller sur le site www.php.net
m'ont permi de trouver le manuel en Français, et les fonctions
base64_encode(), base64_decode(). Ca m'aurait étonné qu'un langage
vieux de 10 ans, et qui plus est orienté Web, n'intègre pas cette
fonctionnalité en standard...
oui ca je sais , mais le language qui crypte n'est pas php. php decrypte et
donc suivant le systeme ou l'on install (surtout pour les mobile) il faut
les dll adequates
donc il faut un cryptage assez complexe mais pas trop car sinon on passe
directment en ssl
Attention aux gros mots, l'aiguille du troll-o-mètre grimpe vers le
rouge... Le gap entre un Vigenère et ce qu'on emploie en SSL n'est pas
de ceux qu'on parcours les doigts dans le nez, après avoir regardé un
reportage sur M6 (ou Arte, ça marche aussi).
le logiciel propose 1 cryptage (dont on parle) mais aussi de passer en SSL
[...]
"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Donc en Français sans fautes connues de vous... Déjà, savoir que c'est
du Français, c'est bien...
Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
oui un derivé, mais c'est la meme technique
Non. Ce que vous fournissez n'est *pas* un Vigenère *dérivé*, c'est un
Vigenère. Point. Que vous fassiez mille transformations de clés ne
change rien, même si au final ce qui chiffre votre texte est une
variable s'appelant $MonTrucEnPlumes, et que vous appelez une "DLL"
codée à partir d'un source en Ruby. Dans la "nouvelle" version (qui
est certainement mieux que l'ancienne; à ce sujet, vous ne voulez
vraiment pas faire de marketing? vous semblez avoir des dispositions),
vous chiffrez avec quelque chose qui est la somme de
PublicKey+PrivateKey, 2 constantes de 16 caractères. La clé effective
est donc une constante de 16 caractères, entièrement déterminés par
PublicKey. C'est un Vigenère.
La "nouvelle version" n'améliore donc pas le système de chiffrement,
qui reste un Vigenère, comme l'ancienne. Les biais statistiques sont
très certainement modifiés, mais je ne sais pas (encore) dans quel
sens. Peu importe, ce sera attaqué comme un Vigenère (au fait, vous
savez que vous avez codé un Vigenère?), et la "clé" trouvée sera la
somme PublicKey+PrivateKey (somme effectuée caractère par caractère,
en prenant la valeur "ASCII" de chaque caractère, sans modulo).
[...]
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Toujours pas de réponse à ce sujet. Vous lisez en diagonale? Ce serait
mesquin de votre part...
le point important dans le dev du logiciel etait que l'utilisateur puisse
[...]
Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
j'ai toujours la version origniale. et la nouvelle version
Bien. Le chiffré du nouveau défi a la même taille, j'en conclus qu'il
provient du même clair, j'ai bon? C'est chiffré avec la même
"PublicKey"?
oui exactement je n'ai changer que le script php et la partie du logiciel
S'il vous plait, ajoutez la compétence "je ne quote pas comme un
goret" dans vos bonnes résolutions du mois d'août...
<mode "oh, que je suis méchant">
Non, sérieusement, si j'étais conseiller d'orientation, je vous dirais
qu'avec de telles dispositions, laissez tomber la technique, allez
vers le marketing. Ou postulez chez Accenture, au choix <g>...
</mode "oh, que je suis méchant">
ca depend de notre specialite et la crypto n'est pas la mienne.
Bon... Je bosse quand, moi? Hein?
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Pour les reponses privees, j'aurais pu ajouter mon adresse dans
un reply block crypte avec pgp et demander de le poster
à remailer@replay.com
-+- A in GNU - En revanche, me présenter c'est un peu dur. -+-
Bonjour,
Hodie III Non. Aug. MMVI est, Firetox scripsit:"Erwann ABALEA" a écrit dans le message de news:Hodie III Non. Aug. MMVI est, Firetox scripsit:[...]
en fait c'etait pour avoir des valeur ascii, ca augmente de 3 mais je
travaille en ascii
Il y a d'autres encodages moins gourmands (par exemple le Base64, qui
n'augmente "que" de 33%.
oui mais le probleme est le language codant ou cryptant qui n'a pas de
fonction permettant cela dans dll exterieur
Uh? "Google est ton ami" (tm). La conversion de/vers Base64 tient en
quelques lignes, pas besoin de DLL machin bidule truc... Trouvez un
autre argumentaire, le B.S. passe assez mal, ici...
Vous faites du PHP, c'est ça? 5 mn à fouiller sur le site www.php.net
m'ont permi de trouver le manuel en Français, et les fonctions
base64_encode(), base64_decode(). Ca m'aurait étonné qu'un langage
vieux de 10 ans, et qui plus est orienté Web, n'intègre pas cette
fonctionnalité en standard...
oui ca je sais , mais le language qui crypte n'est pas php. php decrypte et
donc suivant le systeme ou l'on install (surtout pour les mobile) il faut
les dll adequates
donc il faut un cryptage assez complexe mais pas trop car sinon on passe
directment en ssl
Attention aux gros mots, l'aiguille du troll-o-mètre grimpe vers le
rouge... Le gap entre un Vigenère et ce qu'on emploie en SSL n'est pas
de ceux qu'on parcours les doigts dans le nez, après avoir regardé un
reportage sur M6 (ou Arte, ça marche aussi).
le logiciel propose 1 cryptage (dont on parle) mais aussi de passer en SSL
[...]"Officiel"... en Anglais, Français, Russe, autre? Ecrit avec ou sans
fautes? (quoique ça ne doit pas géner tant que ça pour l'analyse)
en francais sans fautes
Donc en Français sans fautes connues de vous... Déjà, savoir que c'est
du Français, c'est bien...Vous avez compris que le défi proposé n'était rien d'autre que du
Vigenère, n'est-ce pas?
oui un derivé, mais c'est la meme technique
Non. Ce que vous fournissez n'est *pas* un Vigenère *dérivé*, c'est un
Vigenère. Point. Que vous fassiez mille transformations de clés ne
change rien, même si au final ce qui chiffre votre texte est une
variable s'appelant $MonTrucEnPlumes, et que vous appelez une "DLL"
codée à partir d'un source en Ruby. Dans la "nouvelle" version (qui
est certainement mieux que l'ancienne; à ce sujet, vous ne voulez
vraiment pas faire de marketing? vous semblez avoir des dispositions),
vous chiffrez avec quelque chose qui est la somme de
PublicKey+PrivateKey, 2 constantes de 16 caractères. La clé effective
est donc une constante de 16 caractères, entièrement déterminés par
PublicKey. C'est un Vigenère.
La "nouvelle version" n'améliore donc pas le système de chiffrement,
qui reste un Vigenère, comme l'ancienne. Les biais statistiques sont
très certainement modifiés, mais je ne sais pas (encore) dans quel
sens. Peu importe, ce sera attaqué comme un Vigenère (au fait, vous
savez que vous avez codé un Vigenère?), et la "clé" trouvée sera la
somme PublicKey+PrivateKey (somme effectuée caractère par caractère,
en prenant la valeur "ASCII" de chaque caractère, sans modulo).
[...]Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Toujours pas de réponse à ce sujet. Vous lisez en diagonale? Ce serait
mesquin de votre part...
le point important dans le dev du logiciel etait que l'utilisateur puisse
[...]Quant à votre défi initial, il tient toujours? Vous avez conservé la
release 'n' de votre algo/programme pour vérifier, ou vous ètes déjà
passé à la release 'n+15'? Parce que si quelqu'un est en train de
plancher dessus et que vous avez décidé de votre propre chef que
c'était inutile, dites-le tout de suite...
j'ai toujours la version origniale. et la nouvelle version
Bien. Le chiffré du nouveau défi a la même taille, j'en conclus qu'il
provient du même clair, j'ai bon? C'est chiffré avec la même
"PublicKey"?
oui exactement je n'ai changer que le script php et la partie du logiciel
S'il vous plait, ajoutez la compétence "je ne quote pas comme un
goret" dans vos bonnes résolutions du mois d'août...
<mode "oh, que je suis méchant">
Non, sérieusement, si j'étais conseiller d'orientation, je vous dirais
qu'avec de telles dispositions, laissez tomber la technique, allez
vers le marketing. Ou postulez chez Accenture, au choix <g>...
</mode "oh, que je suis méchant">
ca depend de notre specialite et la crypto n'est pas la mienne.
Bon... Je bosse quand, moi? Hein?
--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Pour les reponses privees, j'aurais pu ajouter mon adresse dans
un reply block crypte avec pgp et demander de le poster
à
-+- A in GNU - En revanche, me présenter c'est un peu dur. -+-
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous
pourrez voir. mais j'attend un peu. en fait il existe un projet qui
utllise le cryptage et depuis 2 ans que je l'utilise si ca marchait
pas je m'en serait rendu compte : non ?
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?(3) essaies de le casser par toi même : c'est formateur et tu vois
les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas
specialiste du cassage de cryptage, je pensais que le lieu etait
appropie pour avoir des reponse
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous
pourrez voir. mais j'attend un peu. en fait il existe un projet qui
utllise le cryptage et depuis 2 ans que je l'utilise si ca marchait
pas je m'en serait rendu compte : non ?
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?
(3) essaies de le casser par toi même : c'est formateur et tu vois
les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas
specialiste du cassage de cryptage, je pensais que le lieu etait
appropie pour avoir des reponse
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous
pourrez voir. mais j'attend un peu. en fait il existe un projet qui
utllise le cryptage et depuis 2 ans que je l'utilise si ca marchait
pas je m'en serait rendu compte : non ?
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?(3) essaies de le casser par toi même : c'est formateur et tu vois
les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas
specialiste du cassage de cryptage, je pensais que le lieu etait
appropie pour avoir des reponse
"Erwann ABALEA" a écrit dans le message de news:
[... en boucle ...]
oui ca je sais , mais le language qui crypte n'est pas php. php decrypte et
crypte
la reponse le logiciel qui envoi lui crypte la demande et decrypte la
reponse. mais
le language de prog n'a pas comme php de fonctions natives pour le cryptage
en base 64 par exemple
c'est possible mais en ajoutant des dll.
le logiciel propose 1 cryptage (dont on parle) mais aussi de passer en SSL
donc a ce moment il ne crypte plus.
[...]Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Toujours pas de réponse à ce sujet. Vous lisez en diagonale? Ce serait
mesquin de votre part...
le point important dans le dev du logiciel etait que l'utilisateur puisse
saisir
ca cle ou son mot de passe mais je ne veux pas le transmettre en meme temps
que les demandes
pour eviter de faire transiter le mot de passe. il est donc egalement inclu
dans la partie php en tant que
public.
S'il vous plait, ajoutez la compétence "je ne quote pas comme un
goret" dans vos bonnes résolutions du mois d'août...
je vais y pense mais outlook fait un peu ce qu'il veut
<mode "oh, que je suis méchant">
Non, sérieusement, si j'étais conseiller d'orientation, je vous dirais
qu'avec de telles dispositions, laissez tomber la technique, allez
vers le marketing. Ou postulez chez Accenture, au choix <g>...
</mode "oh, que je suis méchant">
ca depend de notre specialite et la crypto n'est pas la mienne.
je suis plutot cote base de données et developpement.
"Erwann ABALEA" <erwann@abalea.com> a écrit dans le message de news:
20060803153801.GA7265@seclogd.org...
[... en boucle ...]
oui ca je sais , mais le language qui crypte n'est pas php. php decrypte et
crypte
la reponse le logiciel qui envoi lui crypte la demande et decrypte la
reponse. mais
le language de prog n'a pas comme php de fonctions natives pour le cryptage
en base 64 par exemple
c'est possible mais en ajoutant des dll.
le logiciel propose 1 cryptage (dont on parle) mais aussi de passer en SSL
donc a ce moment il ne crypte plus.
[...]
Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Toujours pas de réponse à ce sujet. Vous lisez en diagonale? Ce serait
mesquin de votre part...
le point important dans le dev du logiciel etait que l'utilisateur puisse
saisir
ca cle ou son mot de passe mais je ne veux pas le transmettre en meme temps
que les demandes
pour eviter de faire transiter le mot de passe. il est donc egalement inclu
dans la partie php en tant que
public.
S'il vous plait, ajoutez la compétence "je ne quote pas comme un
goret" dans vos bonnes résolutions du mois d'août...
je vais y pense mais outlook fait un peu ce qu'il veut
<mode "oh, que je suis méchant">
Non, sérieusement, si j'étais conseiller d'orientation, je vous dirais
qu'avec de telles dispositions, laissez tomber la technique, allez
vers le marketing. Ou postulez chez Accenture, au choix <g>...
</mode "oh, que je suis méchant">
ca depend de notre specialite et la crypto n'est pas la mienne.
je suis plutot cote base de données et developpement.
"Erwann ABALEA" a écrit dans le message de news:
[... en boucle ...]
oui ca je sais , mais le language qui crypte n'est pas php. php decrypte et
crypte
la reponse le logiciel qui envoi lui crypte la demande et decrypte la
reponse. mais
le language de prog n'a pas comme php de fonctions natives pour le cryptage
en base 64 par exemple
c'est possible mais en ajoutant des dll.
le logiciel propose 1 cryptage (dont on parle) mais aussi de passer en SSL
donc a ce moment il ne crypte plus.
[...]Vous n'avez pas compris. L'étape de transformation PublicKey vers
PrivateKey *affaiblit* votre système, vous n'en avez pas besoin, vous
auriez tout aussi bien pu effectuer votre chiffrement en travaillant
avec PublicKey à la place de PrivateKey, ça aurait fonctionné tout
pareil.
Toujours pas de réponse à ce sujet. Vous lisez en diagonale? Ce serait
mesquin de votre part...
le point important dans le dev du logiciel etait que l'utilisateur puisse
saisir
ca cle ou son mot de passe mais je ne veux pas le transmettre en meme temps
que les demandes
pour eviter de faire transiter le mot de passe. il est donc egalement inclu
dans la partie php en tant que
public.
S'il vous plait, ajoutez la compétence "je ne quote pas comme un
goret" dans vos bonnes résolutions du mois d'août...
je vais y pense mais outlook fait un peu ce qu'il veut
<mode "oh, que je suis méchant">
Non, sérieusement, si j'étais conseiller d'orientation, je vous dirais
qu'avec de telles dispositions, laissez tomber la technique, allez
vers le marketing. Ou postulez chez Accenture, au choix <g>...
</mode "oh, que je suis méchant">
ca depend de notre specialite et la crypto n'est pas la mienne.
je suis plutot cote base de données et developpement.
À (at) Thu, 3 Aug 2006 17:16:32 +0200,
"Firetox" écrivait (wrote):(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous
pourrez voir. mais j'attend un peu. en fait il existe un projet qui
utllise le cryptage et depuis 2 ans que je l'utilise si ca marchait
pas je m'en serait rendu compte : non ?
Pas obligatoirement... Sauf si vous avez réalisé des jeux de tests
exhaustifs. Et encore...
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?(3) essaies de le casser par toi même : c'est formateur et tu vois
les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas
specialiste du cassage de cryptage, je pensais que le lieu etait
appropie pour avoir des reponse
Ben justement, les réponses fournies ici contiennent tout ce qu'il
vous faut pour tenter vous-même de décrypter votre message. Il suffit
de faire un peu de statistique, peut-être de disposer d'un texte
chiffré un peu plus long pour faciliter la tâche... et surtout d'avoir
du temps à y consacrer. Comme vous avez, évidemment, tout cela sous
la main, ça ne devrait pas être problèmatique... pour vous !
À la question "combien de temps ?", la réponse est "un certain temps"
ou "42".
belle lapalissade
Sans enjeu, le jeu n'en vaut pas la chandelle...
sc
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 3 Aug 2006 17:16:32 +0200,
"Firetox" <emprin.frederic@SQLManagerX.com> écrivait (wrote):
(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous
pourrez voir. mais j'attend un peu. en fait il existe un projet qui
utllise le cryptage et depuis 2 ans que je l'utilise si ca marchait
pas je m'en serait rendu compte : non ?
Pas obligatoirement... Sauf si vous avez réalisé des jeux de tests
exhaustifs. Et encore...
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?
(3) essaies de le casser par toi même : c'est formateur et tu vois
les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas
specialiste du cassage de cryptage, je pensais que le lieu etait
appropie pour avoir des reponse
Ben justement, les réponses fournies ici contiennent tout ce qu'il
vous faut pour tenter vous-même de décrypter votre message. Il suffit
de faire un peu de statistique, peut-être de disposer d'un texte
chiffré un peu plus long pour faciliter la tâche... et surtout d'avoir
du temps à y consacrer. Comme vous avez, évidemment, tout cela sous
la main, ça ne devrait pas être problèmatique... pour vous !
À la question "combien de temps ?", la réponse est "un certain temps"
ou "42".
belle lapalissade
Sans enjeu, le jeu n'en vaut pas la chandelle...
sc
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Thu, 3 Aug 2006 17:16:32 +0200,
"Firetox" écrivait (wrote):(1) assure toi de savoir déchiffrer correctement ce que tu chiffre,
quant au codage decodage , je vais le mettre en ligne comme ca vous
pourrez voir. mais j'attend un peu. en fait il existe un projet qui
utllise le cryptage et depuis 2 ans que je l'utilise si ca marchait
pas je m'en serait rendu compte : non ?
Pas obligatoirement... Sauf si vous avez réalisé des jeux de tests
exhaustifs. Et encore...
(2) renseigne toi plus sur le chiffrement,
comment suis je arrive sur cette news sans un minimum de recherche ?(3) essaies de le casser par toi même : c'est formateur et tu vois
les choses sous un autre angle.
j'essaye de le casse depuis un petit moment , mais n'etant pas
specialiste du cassage de cryptage, je pensais que le lieu etait
appropie pour avoir des reponse
Ben justement, les réponses fournies ici contiennent tout ce qu'il
vous faut pour tenter vous-même de décrypter votre message. Il suffit
de faire un peu de statistique, peut-être de disposer d'un texte
chiffré un peu plus long pour faciliter la tâche... et surtout d'avoir
du temps à y consacrer. Comme vous avez, évidemment, tout cela sous
la main, ça ne devrait pas être problèmatique... pour vous !
À la question "combien de temps ?", la réponse est "un certain temps"
ou "42".
belle lapalissade
Sans enjeu, le jeu n'en vaut pas la chandelle...
sc
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
