Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez
simple, basé sur rien de mathématique ni de connu et qu'a ma connaissance ne
doit pas se craquer si facilement.
Les sources ont été distribués, et en voici le fonctionnement, en vrac :
1) un nombre purement random sur 16 bits est determiné par la lecture de
quelques timer propre au hardware et sert de SEED pour un générateur de
nombre aléatoire
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046 bytes
XORé, la clé d'origine est stockée.
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert qu'a
initialiser une autre fonction de random
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi
générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une
position vers une autre.
6b) chaque byte lu influence le random lui même afin d'obtenir un effet
d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin,
la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Les sources doivent être encore trouvables...ainsi que l'outil lui même.
Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez simple, basé sur rien de mathématique ni de connu et qu'a ma connaissance ne doit pas se craquer si facilement.
Je ne passe que rarement ici. En gros 1-2 fois par mois ou lorsqu'on me prévient qu'il y a des choses intéressantes. Précise un peu plus donc...
Les sources ont été distribués,
Si t'avais un lien, ce serait bien mieux.
et en voici le fonctionnement, en vrac :
1) un nombre purement random sur 16 bits est determiné par la lecture de quelques timer propre au hardware et sert de SEED pour un générateur de nombre aléatoire
Qualité des timers hard ? Qualité du second générateur ?
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046 bytes XORé, la clé d'origine est stockée.
Répétée pour chaque bloc de 2048 octets ? C'est la même pour tous les blocs ou elle diffère pour chaque bloc ?
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert qu'a initialiser une autre fonction de random
Qualité de cette fonction de random ?
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une position vers une autre. 6b) chaque byte lu influence le random lui même afin d'obtenir un effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Comme ça là, on peut pas dire grand chose. Ce n'est pas parce que tu multiplies les étapes, ajoute des couches de "hasard", etc. que c'est solide. Certes, XOR, séparation par bit, randomisation étagée, on part déjà sur d'autres bases que AllCrypter... Mais bon, une étude un peu plus sérieuse est nécessaire pour se faire une idée. Il rame pas un peu ton algo là au fait ?
Les sources doivent être encore trouvables...ainsi que l'outil lui même.
Oui, ben un lien ferait gagner du temps. Voire même si quelques textes on déjà été écrits dessus, ce serait sympa de les avoir.
Qu'en pense les spécialistes du hacking ?
J'en pense que je n'ai pas beaucoup de temps libre, donc, si tu veux une impression, il faut me donner plus de détails, d'exemples, de liens. De prime abord, cela à l'air assez bien fait, tout au moins on ne vois pas un biais/erreur énorme comme dans AllCrypter par exemple. Les XOR c'est pénible à inverser dès que tu t'amuses un peux sérieusement avec. Mais bon, faut voir...
-- AMcD®
http://arnold.mcdonald.free.fr/
arm7 wrote:
Bonjour tout le monde et surtout AMcD(r) !
Salut. Heu, se connaît-on ?
Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez
simple, basé sur rien de mathématique ni de connu et qu'a ma
connaissance ne doit pas se craquer si facilement.
Je ne passe que rarement ici. En gros 1-2 fois par mois ou lorsqu'on me
prévient qu'il y a des choses intéressantes. Précise un peu plus donc...
Les sources ont été distribués,
Si t'avais un lien, ce serait bien mieux.
et en voici le fonctionnement, en
vrac :
1) un nombre purement random sur 16 bits est determiné par la lecture
de quelques timer propre au hardware et sert de SEED pour un
générateur de nombre aléatoire
Qualité des timers hard ? Qualité du second générateur ?
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046
bytes XORé, la clé d'origine est stockée.
Répétée pour chaque bloc de 2048 octets ? C'est la même pour tous les blocs
ou elle diffère pour chaque bloc ?
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert
qu'a initialiser une autre fonction de random
Qualité de cette fonction de random ?
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires
ainsi générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul,
d'une position vers une autre.
6b) chaque byte lu influence le random lui même afin d'obtenir un
effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du
bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout
l'ensemble qui restera crypté.
Comme ça là, on peut pas dire grand chose. Ce n'est pas parce que tu
multiplies les étapes, ajoute des couches de "hasard", etc. que c'est
solide. Certes, XOR, séparation par bit, randomisation étagée, on part déjà
sur d'autres bases que AllCrypter... Mais bon, une étude un peu plus
sérieuse est nécessaire pour se faire une idée. Il rame pas un peu ton algo
là au fait ?
Les sources doivent être encore trouvables...ainsi que l'outil lui
même.
Oui, ben un lien ferait gagner du temps. Voire même si quelques textes on
déjà été écrits dessus, ce serait sympa de les avoir.
Qu'en pense les spécialistes du hacking ?
J'en pense que je n'ai pas beaucoup de temps libre, donc, si tu veux une
impression, il faut me donner plus de détails, d'exemples, de liens. De
prime abord, cela à l'air assez bien fait, tout au moins on ne vois pas un
biais/erreur énorme comme dans AllCrypter par exemple. Les XOR c'est pénible
à inverser dès que tu t'amuses un peux sérieusement avec. Mais bon, faut
voir...
Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez simple, basé sur rien de mathématique ni de connu et qu'a ma connaissance ne doit pas se craquer si facilement.
Je ne passe que rarement ici. En gros 1-2 fois par mois ou lorsqu'on me prévient qu'il y a des choses intéressantes. Précise un peu plus donc...
Les sources ont été distribués,
Si t'avais un lien, ce serait bien mieux.
et en voici le fonctionnement, en vrac :
1) un nombre purement random sur 16 bits est determiné par la lecture de quelques timer propre au hardware et sert de SEED pour un générateur de nombre aléatoire
Qualité des timers hard ? Qualité du second générateur ?
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046 bytes XORé, la clé d'origine est stockée.
Répétée pour chaque bloc de 2048 octets ? C'est la même pour tous les blocs ou elle diffère pour chaque bloc ?
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert qu'a initialiser une autre fonction de random
Qualité de cette fonction de random ?
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une position vers une autre. 6b) chaque byte lu influence le random lui même afin d'obtenir un effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Comme ça là, on peut pas dire grand chose. Ce n'est pas parce que tu multiplies les étapes, ajoute des couches de "hasard", etc. que c'est solide. Certes, XOR, séparation par bit, randomisation étagée, on part déjà sur d'autres bases que AllCrypter... Mais bon, une étude un peu plus sérieuse est nécessaire pour se faire une idée. Il rame pas un peu ton algo là au fait ?
Les sources doivent être encore trouvables...ainsi que l'outil lui même.
Oui, ben un lien ferait gagner du temps. Voire même si quelques textes on déjà été écrits dessus, ce serait sympa de les avoir.
Qu'en pense les spécialistes du hacking ?
J'en pense que je n'ai pas beaucoup de temps libre, donc, si tu veux une impression, il faut me donner plus de détails, d'exemples, de liens. De prime abord, cela à l'air assez bien fait, tout au moins on ne vois pas un biais/erreur énorme comme dans AllCrypter par exemple. Les XOR c'est pénible à inverser dès que tu t'amuses un peux sérieusement avec. Mais bon, faut voir...
-- AMcD®
http://arnold.mcdonald.free.fr/
arm7
Salut. Heu, se connaît-on ? ben j'ai lu tes derniers "posts"... du coup moi je te connais !
Les sources ont été distribués, Si t'avais un lien, ce serait bien mieux.
Pas un lien, des mails. Je dois l'avoir archivé dans un coin, mais c'est en
assembleur 80x86, tu sais lire ca ?
Qualité des timers hard ? Qualité du second générateur ? bonne qualité, le port 40h du PC si j'ai bonne mémoire, il se decremente de
1 tout les 1/1.192.752 fois ou un truc comme ca. C'est un 16 bits. Il était associé a 2 ou trois autres "machins". Le générateur de nombre avec une graine de 16 bits plutot pas mal a ce que j'ai pu en juger.
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046 bytes XORé, la clé d'origine est stockée.
Répétée pour chaque bloc de 2048 octets ? C'est la même pour tous les blocs
ou elle diffère pour chaque bloc ?
La valeur de XOR est prise du générateur a chaque mot de 16 bits, et change pour tous les blocs évidement. Je crois même que la valeur du mot lu est utilisée pour rebrouiller le générateur de nombre...
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert qu'a initialiser une autre fonction de random
Qualité de cette fonction de random ? Ca semble beton, seul "truc" les variables du générateur ont moins de bit
que la clé... mais le programme du mec était une "démo"
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une position vers une autre. 6b) chaque byte lu influence le random lui même afin d'obtenir un effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Comme ça là, on peut pas dire grand chose. Ce n'est pas parce que tu multiplies les étapes, ajoute des couches de "hasard", etc. que c'est solide. Certes, XOR, séparation par bit, randomisation étagée, on part déjà
sur d'autres bases que AllCrypter... Mais bon, une étude un peu plus sérieuse est nécessaire pour se faire une idée. Il rame pas un peu ton algo
là au fait ?
Le mec connait l'assembleur sur le bout des doigts visiblement, il à a utilsé des trucs de la mort comme le BTS, BTC, qui permet des opérations bit a bit. Evidement ca bourre mais surement moins que des truc purement mathématiques !
J'en pense que je n'ai pas beaucoup de temps libre, donc, si tu veux une impression, il faut me donner plus de détails, d'exemples, de liens. De prime abord, cela à l'air assez bien fait, tout au moins on ne vois pas un biais/erreur énorme comme dans AllCrypter par exemple. Les XOR c'est pénible
à inverser dès que tu t'amuses un peux sérieusement avec. Mais bon, faut voir...
J'ai un ".exe", tu le veux ? je l'envoie ou ?
Pour info, le mec a ete raillé par des blaireaux sur ce même forum qui n'ont jamais réussi a trouver une quelconque faille.
Mais le gars a un peu cherché, il a prétendu qu'on avait pas besoin de math pour un encryptage symétrique :-)
http://arnold.mcdonald.free.fr/
Salut. Heu, se connaît-on ?
ben j'ai lu tes derniers "posts"... du coup moi je te connais !
Les sources ont été distribués,
Si t'avais un lien, ce serait bien mieux.
Pas un lien, des mails. Je dois l'avoir archivé dans un coin, mais c'est en
assembleur 80x86, tu sais lire ca ?
Qualité des timers hard ? Qualité du second générateur ?
bonne qualité, le port 40h du PC si j'ai bonne mémoire, il se decremente de
1 tout les 1/1.192.752 fois ou un truc comme ca. C'est un 16 bits. Il était
associé a 2 ou trois autres "machins".
Le générateur de nombre avec une graine de 16 bits plutot pas mal a ce que
j'ai pu en juger.
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046
bytes XORé, la clé d'origine est stockée.
Répétée pour chaque bloc de 2048 octets ? C'est la même pour tous les
blocs
ou elle diffère pour chaque bloc ?
La valeur de XOR est prise du générateur a chaque mot de 16 bits, et change
pour tous les blocs évidement. Je crois même que la valeur du mot lu est
utilisée pour rebrouiller le générateur de nombre...
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert
qu'a initialiser une autre fonction de random
Qualité de cette fonction de random ?
Ca semble beton, seul "truc" les variables du générateur ont moins de bit
que la clé... mais le programme du mec était une "démo"
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires
ainsi générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul,
d'une position vers une autre.
6b) chaque byte lu influence le random lui même afin d'obtenir un
effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du
bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout
l'ensemble qui restera crypté.
Comme ça là, on peut pas dire grand chose. Ce n'est pas parce que tu
multiplies les étapes, ajoute des couches de "hasard", etc. que c'est
solide. Certes, XOR, séparation par bit, randomisation étagée, on part
déjà
sur d'autres bases que AllCrypter... Mais bon, une étude un peu plus
sérieuse est nécessaire pour se faire une idée. Il rame pas un peu ton
algo
là au fait ?
Le mec connait l'assembleur sur le bout des doigts visiblement, il à a
utilsé des trucs de la mort comme le BTS, BTC, qui permet des opérations bit
a bit. Evidement ca bourre mais surement moins que des truc purement
mathématiques !
J'en pense que je n'ai pas beaucoup de temps libre, donc, si tu veux une
impression, il faut me donner plus de détails, d'exemples, de liens. De
prime abord, cela à l'air assez bien fait, tout au moins on ne vois pas un
biais/erreur énorme comme dans AllCrypter par exemple. Les XOR c'est
pénible
à inverser dès que tu t'amuses un peux sérieusement avec. Mais bon, faut
voir...
J'ai un ".exe", tu le veux ? je l'envoie ou ?
Pour info, le mec a ete raillé par des blaireaux sur ce même forum qui n'ont
jamais réussi a trouver une quelconque faille.
Mais le gars a un peu cherché, il a prétendu qu'on avait pas besoin de math
pour un encryptage symétrique :-)
Salut. Heu, se connaît-on ? ben j'ai lu tes derniers "posts"... du coup moi je te connais !
Les sources ont été distribués, Si t'avais un lien, ce serait bien mieux.
Pas un lien, des mails. Je dois l'avoir archivé dans un coin, mais c'est en
assembleur 80x86, tu sais lire ca ?
Qualité des timers hard ? Qualité du second générateur ? bonne qualité, le port 40h du PC si j'ai bonne mémoire, il se decremente de
1 tout les 1/1.192.752 fois ou un truc comme ca. C'est un 16 bits. Il était associé a 2 ou trois autres "machins". Le générateur de nombre avec une graine de 16 bits plutot pas mal a ce que j'ai pu en juger.
2) l'outil fonctionne par bloc de 2046 bytes (2Ko moins 2 bytes)
3) un XOR est effectué sur chaque 16 bits du bloc, à la fin des 2046 bytes XORé, la clé d'origine est stockée.
Répétée pour chaque bloc de 2048 octets ? C'est la même pour tous les blocs
ou elle diffère pour chaque bloc ?
La valeur de XOR est prise du générateur a chaque mot de 16 bits, et change pour tous les blocs évidement. Je crois même que la valeur du mot lu est utilisée pour rebrouiller le générateur de nombre...
4) le clé de chiffrement qui permet aussi son déchiffrement, ne sert qu'a initialiser une autre fonction de random
Qualité de cette fonction de random ? Ca semble beton, seul "truc" les variables du générateur ont moins de bit
que la clé... mais le programme du mec était une "démo"
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi générée, les vecteurs pointent tous une destination différente
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une position vers une autre. 6b) chaque byte lu influence le random lui même afin d'obtenir un effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Comme ça là, on peut pas dire grand chose. Ce n'est pas parce que tu multiplies les étapes, ajoute des couches de "hasard", etc. que c'est solide. Certes, XOR, séparation par bit, randomisation étagée, on part déjà
sur d'autres bases que AllCrypter... Mais bon, une étude un peu plus sérieuse est nécessaire pour se faire une idée. Il rame pas un peu ton algo
là au fait ?
Le mec connait l'assembleur sur le bout des doigts visiblement, il à a utilsé des trucs de la mort comme le BTS, BTC, qui permet des opérations bit a bit. Evidement ca bourre mais surement moins que des truc purement mathématiques !
J'en pense que je n'ai pas beaucoup de temps libre, donc, si tu veux une impression, il faut me donner plus de détails, d'exemples, de liens. De prime abord, cela à l'air assez bien fait, tout au moins on ne vois pas un biais/erreur énorme comme dans AllCrypter par exemple. Les XOR c'est pénible
à inverser dès que tu t'amuses un peux sérieusement avec. Mais bon, faut voir...
J'ai un ".exe", tu le veux ? je l'envoie ou ?
Pour info, le mec a ete raillé par des blaireaux sur ce même forum qui n'ont jamais réussi a trouver une quelconque faille.
Mais le gars a un peu cherché, il a prétendu qu'on avait pas besoin de math pour un encryptage symétrique :-)
Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez simple, basé sur rien de mathématique ni de connu et qu'a ma connaissance ne doit pas se craquer si facilement.
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi générée, les vecteurs pointent tous une destination différente
Des vecteurs de quelle dimension et dans quel espace ?
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une position vers une autre.
Un bit ou un byte ? Une "position", c'est a considerer dans le message initial (on fait une permutation du message) ou parmi les 256 valeurs que peut prendre un bit ? Premiere hypothese, je suppose. Si c'etait la deuxieme, il ne serait pas necessaire d'exprimer ca en termes de "vecteurs" (c'est une permutation de [0..256]). Et il n'est pas necessaire qu'il y en ait 2048. Donc ce doit etre une permutation de la position des octets. Quoique la aussi, il s'agit d'une permutation
6b) chaque byte lu influence le random lui même afin d'obtenir un effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Ah. Concretement ca veut dire que la fonction "random" est une fonction de la clef de chiffrement et du ou des octets precedemment decode' au sein du message ?
M[j] = C[i] et
j = f(C[i],K,M[j'])
avec j' = f(C[i-1],K,j'')
=> j = f(C[i],C[i-1],..,C[0], K)
Avec : M = message, C = chiffre', i = index de l'octet considere' dans le clair*, j = index de l'octet considere dans le chiffre', K = clef.
*Pas tout a fait le clair, quand meme, le resultat de la 1ere phase du chiffrement, disons.
Ben comme ca, intuitivement, je dirais que la solidite' de l'algo depend de la maniere dont est definie la permutation f(), hein. Ca ne peut pas etre totalement random, quand meme, il faut bien pouvoir definir f^{-1} telle que i = f^{-1} (M[j], C[i-1],..,C[0], K) par exemple et que f soit bien une permutation. Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
Ah, oui, c'est vrai, j'oubliais qu'on avait pas besoin de maths...
-- Tweakie
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
arm7 wrote:
Bonjour tout le monde et surtout AMcD(r) !
Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez
simple, basé sur rien de mathématique ni de connu et qu'a ma connaissance ne
doit pas se craquer si facilement.
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi
générée, les vecteurs pointent tous une destination différente
Des vecteurs de quelle dimension et dans quel espace ?
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une
position vers une autre.
Un bit ou un byte ? Une "position", c'est a considerer dans le message
initial (on fait une permutation du message) ou parmi les 256 valeurs
que peut prendre un bit ? Premiere hypothese, je suppose. Si c'etait la
deuxieme, il ne serait pas necessaire d'exprimer ca en termes de
"vecteurs"
(c'est une permutation de [0..256]). Et il n'est pas necessaire qu'il y en
ait 2048. Donc ce doit etre une permutation de la position des octets.
Quoique la aussi, il s'agit d'une permutation
6b) chaque byte lu influence le random lui même afin d'obtenir un effet
d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin,
la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Ah. Concretement ca veut dire que la fonction "random" est une fonction de
la clef de chiffrement et du ou des octets precedemment decode' au sein du
message ?
M[j] = C[i] et
j = f(C[i],K,M[j'])
avec j' = f(C[i-1],K,j'')
=> j = f(C[i],C[i-1],..,C[0], K)
Avec : M = message, C = chiffre', i = index de l'octet considere' dans le
clair*, j = index de l'octet considere dans le chiffre', K = clef.
*Pas tout a fait le clair, quand meme, le resultat de la 1ere phase
du chiffrement, disons.
Ben comme ca, intuitivement, je dirais que la solidite' de l'algo depend
de la maniere dont est definie la permutation f(), hein. Ca ne peut pas
etre totalement random, quand meme, il faut bien pouvoir definir f^{-1}
telle que i = f^{-1} (M[j], C[i-1],..,C[0], K) par exemple et que f
soit bien une permutation. Le premier truc, quand on veut prouver
qu'une methode est solide, c'est d'en fournir une description claire
et precise.
Ah, oui, c'est vrai, j'oubliais qu'on avait pas besoin de maths...
--
Tweakie
--
Posté via http://www.webatou.net/
Usenet dans votre navigateur !
Complaints-To: abuse@webatou.net
Il y a quelques années, j'ai vu passé ici un méthode de cryptage assez simple, basé sur rien de mathématique ni de connu et qu'a ma connaissance ne doit pas se craquer si facilement.
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique
5) un tableau de 2048 vecteurs est créée avec les nombre alléatoires ainsi générée, les vecteurs pointent tous une destination différente
Des vecteurs de quelle dimension et dans quel espace ?
6) la fonction d'un vecteur est de transporter un bit, et un seul, d'une position vers une autre.
Un bit ou un byte ? Une "position", c'est a considerer dans le message initial (on fait une permutation du message) ou parmi les 256 valeurs que peut prendre un bit ? Premiere hypothese, je suppose. Si c'etait la deuxieme, il ne serait pas necessaire d'exprimer ca en termes de "vecteurs" (c'est une permutation de [0..256]). Et il n'est pas necessaire qu'il y en ait 2048. Donc ce doit etre une permutation de la position des octets. Quoique la aussi, il s'agit d'une permutation
6b) chaque byte lu influence le random lui même afin d'obtenir un effet d'avalanche : Un seul byte mal décodé détruira l'ensemble du bloc. A la fin, la clé sur 16 bits sera fausse et c'est tout l'ensemble qui restera crypté.
Ah. Concretement ca veut dire que la fonction "random" est une fonction de la clef de chiffrement et du ou des octets precedemment decode' au sein du message ?
M[j] = C[i] et
j = f(C[i],K,M[j'])
avec j' = f(C[i-1],K,j'')
=> j = f(C[i],C[i-1],..,C[0], K)
Avec : M = message, C = chiffre', i = index de l'octet considere' dans le clair*, j = index de l'octet considere dans le chiffre', K = clef.
*Pas tout a fait le clair, quand meme, le resultat de la 1ere phase du chiffrement, disons.
Ben comme ca, intuitivement, je dirais que la solidite' de l'algo depend de la maniere dont est definie la permutation f(), hein. Ca ne peut pas etre totalement random, quand meme, il faut bien pouvoir definir f^{-1} telle que i = f^{-1} (M[j], C[i-1],..,C[0], K) par exemple et que f soit bien une permutation. Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
Ah, oui, c'est vrai, j'oubliais qu'on avait pas besoin de maths...
-- Tweakie
-- Posté via http://www.webatou.net/ Usenet dans votre navigateur ! Complaints-To:
Jean-Marc Desperrier
Tweakie wrote:
[...]. Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
Et de la simplifier au maximum pour n'utiliser que les éléments vraiment utiles, c'est à dire ceux dont on sait que la solidité n'a aucune faille.
Le bloc de 2046 de la première étape généré par pseudo-aléa à partir d'une valeur aléatoire de 16 bits est très mauvais de ce point de vue.
Si l'algo a besoin que ces 2048 bits soit réellement solides, c'est pas *du tout* le cas, et s'il n'en a pas besoin, ils ne sont pas réellement utiles et on pourrait simplifier.
Tweakie wrote:
[...]. Le premier truc, quand on veut prouver qu'une
methode est solide, c'est d'en fournir une description claire et precise.
Et de la simplifier au maximum pour n'utiliser que les éléments vraiment
utiles, c'est à dire ceux dont on sait que la solidité n'a aucune faille.
Le bloc de 2046 de la première étape généré par pseudo-aléa à partir
d'une valeur aléatoire de 16 bits est très mauvais de ce point de vue.
Si l'algo a besoin que ces 2048 bits soit réellement solides, c'est pas
*du tout* le cas, et s'il n'en a pas besoin, ils ne sont pas réellement
utiles et on pourrait simplifier.
[...]. Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
Et de la simplifier au maximum pour n'utiliser que les éléments vraiment utiles, c'est à dire ceux dont on sait que la solidité n'a aucune faille.
Le bloc de 2046 de la première étape généré par pseudo-aléa à partir d'une valeur aléatoire de 16 bits est très mauvais de ce point de vue.
Si l'algo a besoin que ces 2048 bits soit réellement solides, c'est pas *du tout* le cas, et s'il n'en a pas besoin, ils ne sont pas réellement utiles et on pourrait simplifier.
AMcD®
Tweakie wrote:
Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
C'est bien pour cela que je ne vais pas me fouler sur l'affaire avec le peu qu'on a...
-- AMcD®
http://arnold.mcdonald.free.fr/
Tweakie wrote:
Le premier truc, quand on veut prouver
qu'une methode est solide, c'est d'en fournir une description claire
et precise.
C'est bien pour cela que je ne vais pas me fouler sur l'affaire avec le peu
qu'on a...
Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
C'est bien pour cela que je ne vais pas me fouler sur l'affaire avec le peu qu'on a...
-- AMcD®
http://arnold.mcdonald.free.fr/
AMcD®
Je n'ai rien reçu. Pourtant, mon adresse n'est pas vraiment compliquée...
Mais ne te fatigue pas. Pour que ton problème soit "intéressant", il me faudrait plus de précisions, des détails, des liens, etc. Un truc consultable par tout le monde. Voire même un problème qui intéresse plusieurs personnes.
J'ai autre chose à faire là que de "travailler" comme ça, sur commande. Je n'ai pas trop le temps. Qui plus est gratos. Et puis, si des gens d'ici ont dit que c'était pas terrible, tu peux les croire : c'est pas terrible :-).
PS : non je ne connais rien à l'assembleur, je hacke uniquement le JavaScript (et encore, si les noms de variables sont en français)...
-- AMcD®
http://arnold.mcdonald.free.fr/
Je n'ai rien reçu. Pourtant, mon adresse n'est pas vraiment compliquée...
Mais ne te fatigue pas. Pour que ton problème soit "intéressant", il me
faudrait plus de précisions, des détails, des liens, etc. Un truc
consultable par tout le monde. Voire même un problème qui intéresse
plusieurs personnes.
J'ai autre chose à faire là que de "travailler" comme ça, sur commande. Je
n'ai pas trop le temps. Qui plus est gratos. Et puis, si des gens d'ici ont
dit que c'était pas terrible, tu peux les croire : c'est pas terrible :-).
PS : non je ne connais rien à l'assembleur, je hacke uniquement le
JavaScript (et encore, si les noms de variables sont en français)...
Je n'ai rien reçu. Pourtant, mon adresse n'est pas vraiment compliquée...
Mais ne te fatigue pas. Pour que ton problème soit "intéressant", il me faudrait plus de précisions, des détails, des liens, etc. Un truc consultable par tout le monde. Voire même un problème qui intéresse plusieurs personnes.
J'ai autre chose à faire là que de "travailler" comme ça, sur commande. Je n'ai pas trop le temps. Qui plus est gratos. Et puis, si des gens d'ici ont dit que c'était pas terrible, tu peux les croire : c'est pas terrible :-).
PS : non je ne connais rien à l'assembleur, je hacke uniquement le JavaScript (et encore, si les noms de variables sont en français)...
-- AMcD®
http://arnold.mcdonald.free.fr/
arm7
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique L'auteur le dit. La lecture du source aussi.
Des vecteurs de quelle dimension et dans quel espace ? Dimension 1.
Depuis le buffer source vers le buffer destination.
Un bit ou un byte ? un bit. 0 ou 1.
Une "position", c'est a considerer dans le message initial (on fait une permutation du message) il y a 16384 positions dans le buffer initial et donc autant dans le buffer
destination.
Mais maintenaque que j'y repense, le buffer devait faire 1022 bytes et donc y a voir 8192 vecteurs. Mais c'est un detail.
ou parmi les 256 valeurs que peut prendre un bit ? Ha bon.
Ah. Concretement ca veut dire que la fonction "random" est une fonction de la clef de chiffrement et du ou des octets precedemment decode' au sein du message ? oui. La clé initiale est celle entrée, mais elle "grossit" avec le message
chiffrée
*Pas tout a fait le clair, quand meme, le resultat de la 1ere phase du chiffrement, disons. A mon avis on pourrait s'en passer.
Par contre grace a ca, 2 fichiers identiques chiffrés avec la même clef donne deux fichiers totalement différents.
Ben comme ca, intuitivement, je dirais que la solidite' de l'algo depend de la maniere dont est definie la permutation f(), hein. Ca ne peut pas etre totalement random, quand meme, il faut bien pouvoir definir f^{-1} telle que i = f^{-1} (M[j], C[i-1],..,C[0], K) par exemple et que f soit bien une permutation. Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
il faut que je retrouve le source alors ! le .exe fait 1400 bytes, le source est lui aussi microscopique, et il y en a qu'un.
De mémoire, la permutation ressemble a un truc comme ca (traduit en C, en ASM ca prend une autre forme)
// creation des vecteurs for (i=0; i<8192; i++) { v[i] = i; }
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique
L'auteur le dit. La lecture du source aussi.
Des vecteurs de quelle dimension et dans quel espace ?
Dimension 1.
Depuis le buffer source vers le buffer destination.
Un bit ou un byte ?
un bit. 0 ou 1.
Une "position", c'est a considerer dans le message
initial (on fait une permutation du message)
il y a 16384 positions dans le buffer initial et donc autant dans le buffer
destination.
Mais maintenaque que j'y repense, le buffer devait faire 1022 bytes et donc
y a voir 8192 vecteurs.
Mais c'est un detail.
ou parmi les 256 valeurs
que peut prendre un bit ?
Ha bon.
Ah. Concretement ca veut dire que la fonction "random" est une fonction de
la clef de chiffrement et du ou des octets precedemment decode' au sein du
message ?
oui. La clé initiale est celle entrée, mais elle "grossit" avec le message
chiffrée
*Pas tout a fait le clair, quand meme, le resultat de la 1ere phase
du chiffrement, disons.
A mon avis on pourrait s'en passer.
Par contre grace a ca, 2 fichiers identiques chiffrés avec la même clef
donne
deux fichiers totalement différents.
Ben comme ca, intuitivement, je dirais que la solidite' de l'algo depend
de la maniere dont est definie la permutation f(), hein. Ca ne peut pas
etre totalement random, quand meme, il faut bien pouvoir definir f^{-1}
telle que i = f^{-1} (M[j], C[i-1],..,C[0], K) par exemple et que f
soit bien une permutation. Le premier truc, quand on veut prouver
qu'une methode est solide, c'est d'en fournir une description claire
et precise.
il faut que je retrouve le source alors !
le .exe fait 1400 bytes, le source est lui aussi microscopique, et il y en a
qu'un.
De mémoire, la permutation ressemble a un truc comme ca (traduit en C, en
ASM ca prend une autre forme)
// creation des vecteurs
for (i=0; i<8192; i++)
{
v[i] = i;
}
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique L'auteur le dit. La lecture du source aussi.
Des vecteurs de quelle dimension et dans quel espace ? Dimension 1.
Depuis le buffer source vers le buffer destination.
Un bit ou un byte ? un bit. 0 ou 1.
Une "position", c'est a considerer dans le message initial (on fait une permutation du message) il y a 16384 positions dans le buffer initial et donc autant dans le buffer
destination.
Mais maintenaque que j'y repense, le buffer devait faire 1022 bytes et donc y a voir 8192 vecteurs. Mais c'est un detail.
ou parmi les 256 valeurs que peut prendre un bit ? Ha bon.
Ah. Concretement ca veut dire que la fonction "random" est une fonction de la clef de chiffrement et du ou des octets precedemment decode' au sein du message ? oui. La clé initiale est celle entrée, mais elle "grossit" avec le message
chiffrée
*Pas tout a fait le clair, quand meme, le resultat de la 1ere phase du chiffrement, disons. A mon avis on pourrait s'en passer.
Par contre grace a ca, 2 fichiers identiques chiffrés avec la même clef donne deux fichiers totalement différents.
Ben comme ca, intuitivement, je dirais que la solidite' de l'algo depend de la maniere dont est definie la permutation f(), hein. Ca ne peut pas etre totalement random, quand meme, il faut bien pouvoir definir f^{-1} telle que i = f^{-1} (M[j], C[i-1],..,C[0], K) par exemple et que f soit bien une permutation. Le premier truc, quand on veut prouver qu'une methode est solide, c'est d'en fournir une description claire et precise.
il faut que je retrouve le source alors ! le .exe fait 1400 bytes, le source est lui aussi microscopique, et il y en a qu'un.
De mémoire, la permutation ressemble a un truc comme ca (traduit en C, en ASM ca prend une autre forme)
// creation des vecteurs for (i=0; i<8192; i++) { v[i] = i; }
Si l'algo a besoin que ces 2048 bits soit réellement solides, c'est pas *du tout* le cas, et s'il n'en a pas besoin, ils ne sont pas réellement utiles et on pourrait simplifier.
ca permet tout même de diviser par 65536 la performance de toute approche en brute force... ... et d'obtenir un effet d'avalanche tout a fait sympa, non ?
Si l'algo a besoin que ces 2048 bits soit réellement solides, c'est pas
*du tout* le cas, et s'il n'en a pas besoin, ils ne sont pas réellement
utiles et on pourrait simplifier.
ca permet tout même de diviser par 65536 la performance de toute approche en
brute force...
... et d'obtenir un effet d'avalanche tout a fait sympa, non ?
Si l'algo a besoin que ces 2048 bits soit réellement solides, c'est pas *du tout* le cas, et s'il n'en a pas besoin, ils ne sont pas réellement utiles et on pourrait simplifier.
ca permet tout même de diviser par 65536 la performance de toute approche en brute force... ... et d'obtenir un effet d'avalanche tout a fait sympa, non ?
arm7
normal si t'es chez free, desfois ca prend bien 8 a 12 heures pour acheminer un mail.
patience.
Mais ne te fatigue pas. Pour que ton problème soit "intéressant", il me faudrait plus de précisions, des détails, des liens, etc. Un truc consultable par tout le monde. Voire même un problème qui intéresse plusieurs personnes.
ok, ok, quand j'ai vu avec quelle ardeur tu as humilié Allcrypt, je me suis dit que j'aurai enfin le fin mot de l'histoire !
mais c'est pas grave !
normal si t'es chez free, desfois ca prend bien 8 a 12 heures pour acheminer
un mail.
patience.
Mais ne te fatigue pas. Pour que ton problème soit "intéressant", il me
faudrait plus de précisions, des détails, des liens, etc. Un truc
consultable par tout le monde. Voire même un problème qui intéresse
plusieurs personnes.
ok, ok, quand j'ai vu avec quelle ardeur tu as humilié Allcrypt, je me suis
dit que j'aurai enfin le fin mot de l'histoire !
normal si t'es chez free, desfois ca prend bien 8 a 12 heures pour acheminer un mail.
patience.
Mais ne te fatigue pas. Pour que ton problème soit "intéressant", il me faudrait plus de précisions, des détails, des liens, etc. Un truc consultable par tout le monde. Voire même un problème qui intéresse plusieurs personnes.
ok, ok, quand j'ai vu avec quelle ardeur tu as humilié Allcrypt, je me suis dit que j'aurai enfin le fin mot de l'histoire !
