AMcD® : méthode de cryptage.
Le
arm7
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.
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 trouvablesainsi que l'outil lui même.
Qu'en pense les spécialistes du hacking ?
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 trouvablesainsi que l'outil lui même.
Qu'en pense les spécialistes du hacking ?
Poser une question
Salut. Heu, se connaît-on ?
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...
Si t'avais un lien, ce serait bien mieux.
Qualité des timers hard ? Qualité du second générateur ?
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 ?
Qualité de cette fonction de random ?
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 ?
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.
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/
assembleur 80x86, tu sais lire ca ?
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.
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...
que la clé... mais le programme du mec était une "démo"
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'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 :-)
J'ai envoyé le .exe...
Qu'est-ce qui vous fait dire qu'il n'y a pas de base mathematique
Des vecteurs de quelle dimension et dans quel espace ?
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
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:
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.