ALGORITHME DE CRYPTAGE DE 128 OU 256 BITS : PC1 ENCRYPTION CIPHER
cs_ManChesTer
Messages postés
374
Date d'inscription
vendredi 20 octobre 2000
Statut
Modérateur
Dernière intervention
15 janvier 2021
-
24 févr. 2003 à 14:04
PhilLu Messages postés 251 Date d'inscription lundi 9 novembre 2009 Statut Membre Dernière intervention 11 mai 2021 - 8 juin 2015 à 22:44
PhilLu Messages postés 251 Date d'inscription lundi 9 novembre 2009 Statut Membre Dernière intervention 11 mai 2021 - 8 juin 2015 à 22:44
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/12369-algorithme-de-cryptage-de-128-ou-256-bits-pc1-encryption-cipher
https://codes-sources.commentcamarche.net/source/12369-algorithme-de-cryptage-de-128-ou-256-bits-pc1-encryption-cipher
8 juin 2015 à 22:44
merci,
Philippe
23 févr. 2010 à 18:34
Le message en clair n'est pas absolument pas nécessaire pour déchiffrer un message crypté. Seul est nécessaire le message crypté et la clé.
La clé de déchiffrement est donc la même que celle du chiffrement.
23 févr. 2010 à 10:32
je me suis replongé dans ton algorithme il y a peu. Voici quelques remarques :
- peux-tu préciser dans la source qu'il faut que l'utilisateur puisse récupérer le dernier état de la clef sur 16 bits après avoir été mise à jour pendant le chiffrement ? Car sinon, le déchiffrement ne peut marcher (pour t'en convaincre, chiffre un message avec ton programme, ferme le programme, réouvre le et déchiffre avec la même clef).
- justement, le fait que la clef soit xorée avec le message en clair, fait que le message en clair est implicitement nécessaire au déchiffrement. L'information nécessaire est détenue par la clef (qui est xorée avec le message en clair pendant le chiffrement), du coup cela veut implicitement dire qu'il faut une clef par message (attention : je n'ai pas dit que les clefs n'étaient pas réutilisables, j'ai dit que la clef de déchiffrement est différente de la clef de chiffrement).
A bon entendeur ...
Cordialement, Bacterius !
5 janv. 2010 à 18:23
Mais c'est vrai que par le manque de commentaires sur les points importants de l'algorithme, je n'ai pas saisi la logique de l'algorithme, étant novice en crypto...
2 janv. 2010 à 23:03
2 janv. 2010 à 22:57
Quand à la boucle, dans un souci de rapidité elle n'a pas été ajoutée. En effet, une fois compilé en langage machine c'est plus rapide de faire des accès mémoires directs que d'incrémenter une variable (qui doit être recalculée à chaque incrémentation) mais chacun est libre de modifier l'algorithme.
L'algorithme a été utilisé dans de nombreuses applications commerciales, la plus connue étant le Kindle d'Amazon. L'algorithme étant utilisé pour crypter les livres électroniques vendus par Amazon. (il suffit de chercher kindle pukall cipher 1 sur google)
Ceci étant, beaucoup d'entreprises utilisent cet algorithme sans le dire. Amazon n'a jamais rien dit à ce sujet, c'est simplement par le fait que des hackers ont cassé la protection du Kindle que le fait qu'Amazon utilise mon algorithme est connu.
A noter que l'algorithme n'a jamais été cassé par aucun hacker à ce jour et depuis 1991 (bien sûr bactérius cité plus haut a laissé tomber sa soit disant attaque).
Le cassage de la protection du Kindle est dû, non pas au cassage de mon algorithme mais au fait que la clé fixe qui sert au chiffrement a été retrouvée par un hacker par désassemblage du code compilé. Amazon utilisant la même clé pour crypter tous les livres électroniques qu'elle vend.
En fait pas tout à fait car cette clé fixe est modifiée pour chaque ebook par une procédure spécifique (le Pid).
Mais connaître la clé fixe permet de retrouver toutes les autres clés.
C'est la même chose avec Canal+ numérique et Canal Satellite. Les chaînes sont cryptées avec une clé fixe (et quelques modifications). L'algorithme utilisé par Canal+ est l'AES, aussi bon que mon algorithme et qui d'ailleurs n'a jamais été cassé non plus. Mais les hackers retrouvent la clé fixe utilisée par l'AES et cela permet de décoder les chaînes sans casser l'algorithme.
Le seul moyen qu'une protection de contenu ne soit pas cassée serait qu'il y ait une clé par abonné.
Ce qui signifie que si Canal+ a 3 millions d'abonnés, il devrait crypter chaque chaîne 3 millions de fois différentes (donc il faudrait 3 millions de canaux pour une seule chaîne). Dans ce cas si un abonné retrouve la clé de cryptage (qui est stockée dans la carte à puce) il ne servirait à rien qu'il la diffuse sur le net car les autres abonnés auraient une autre clé.
30 déc. 2009 à 19:14
J'ai eu quelques cours sur la cryptographie en début d'année, et il n'y a rien de plus passionnant que de voir un débat comme ça ! J'viens d'apprendre plein de trucs !
Je ne peux donc rien affirmer quant à la sûreté de ton algorithme Alexander.
J'ai lu le code écrit en C, disponible sur ton site, et s'il y a une chose que je peux dire, c'est que c'est codé avec les pieds !
-> Déclaration "à l'arrache" de variables globales au début de ton fichier
-> L'indentation du code laisse vraiment à désirer
-> Ta série de :
x1a0[15]= x1a0[14] ^ ( (cle[30]*256) + cle[31] );
code();
inter=inter^res;
aurait paru beaucoup moins "bourrin" dans une boucle.
En espérant que ma maigre contribution puisse t'aider !
En tout cas votre débat est génial, vivement le prochain épisode =D
Bien cordialement,
Rodolphe.
3 sept. 2009 à 08:31
Pour SEA, tu as raison, rien n'a été analysé dessus ...
Cordialement, Bacterius !
3 sept. 2009 à 08:25
Plus le texte crypté est long, moins cela devient probable. Sur 16 octets c'est statistiquement impossible.
Bref, je vois que la discussion peut s'éterniser sans fin...
Par contre et si toi tu nous fournissais déjà une analyse de ton propre algo de hachage et de chiffrement qui se base sur ce dernier (qui d'ailleurs est basé sur un MD5 modifié en rajoutant une table de constante de rondes plus grande). Je parle bien entendu de SEA et LEA publiés en Juillet 2009 et déjà modifiés (par souci de sécurité as tu dit) et republiés en Août 2009. J'ai l'impression qu'aucune analyse n'a été faite au préalable puisque tu as déjà fait des modifications à ton algo.
Car c'est bien de vouloir cryptanalyser les algos existants mais ce serait déjà bien que tu nous démontres que SEA et LEA sont sûrs, puisque MD5 a été cassé et que tu te bases sur une version modifiée de MD5.
Cordialement,
3 sept. 2009 à 06:06
Si tu as des infos à donner pour la cryptanalyse, donne les, ça aidera. Ca part dans le sens du principe de Kerchkoff (mais ça, tu le savais déjà).
Cordialement, Bacterius !
3 sept. 2009 à 06:03
"Cela a été démontré avec le DES"
Ouais mais le DES a été cryptanalysé ... toi tu balances un algo sans preuve. Tu ne peux pas considérer un algo sûr simplement sur le fait qu'il n'a pas encore été analysé !
Création ... Analyse => Non sûr
Analyse ... Cryptanalyse réussie => Sûr
Cryptanalyse réussie ... plus tard => Non sûr
Fais nous une cryptanalyse qui prouve sa résistance à la différentielle, à la linéaire et aux autres, sinon ça ne sert à rien. Sans preuves, ton algo n'est pas, et ne sera jamais considéré comme, sûr !
Cordialement, Bacterius !
2 sept. 2009 à 19:34
J'espère que ce n'est pas le cas!
Laisse moi t'indiquer qu'il n'y a qu'un seul message "sensé" pour deux clés différents avec un texte crypté donné pour tous les algorithmes symétriques. Cela a été démontré par exemple avec le DES. Il dispose d'une clé de 56 bits et pour un texte crypté donné, on ne trouve qu'un seul message en clair (ce que tu appelle un message "sensé" en essayant toutes les clés possibles sur 56 bits (2 puissance 56 clés possibles)
Le seul algorithme où deux clés différentes donnent un message "sensé" avec le même texte crypté est le One Time Pad, que l'on appelle également chiffre à usage unique ou parfois aussi chiffre de Vernam.
2 sept. 2009 à 06:02
Cordialement, Bacterius !
2 sept. 2009 à 06:00
De toute façon je suis en train de bosser dessus, une cryptanalyse ne se fait pas en une nuit ;)
Cordialement, Bacterius !
1 sept. 2009 à 22:05
http://www.zataz.com/reportage-securite/6989/Chiffrement.html
1 sept. 2009 à 22:01
http://membres.lycos.fr/pc1/enigma-fr/index.html
1 sept. 2009 à 21:57
Je suis heureux que tu te sois toi-même rendu compte que tu n'as rien cryptanalysé du tout.
Car l'algorithme c'est justement ça : cfc xor cfd
les fameuses variables cfc et cfd sont le coeur de l'algo.
Alors lire ceci : "Je me fiche un peu de (cfc xor cfd), je ne prends pas la peine de le cryptanalyser, mais en le faisant on peut peut-être obtenir de meilleurs résultats." m'a fait doucement rigoler, puisque ceci EST l'algorithme, le reste ce n'est que le mix du message clair et la mise en forme en lettres minuscules au lieu d'utiliser les caractères hexadécimaux.
Bref, ce que tu as écris n'est ABSOLUMENT PAS une cryptanalyse et ne démontre AUCUNE FAILLE.
En fait ce que tu as écris, c'est un peu comme si un médecin disait, bon là vous avez quelques boutons d'acné et ici des métastases qui viennent d'une tumeur cancéreuse. Bon je vous enlève de suite les boutons d'acnés sans attendre. La tumeuse cancéreuse, je vous la laisse, ca n'est pas dangereux...
Dernière chose Bactérius, l'algorithme a été publié en 1991 avec une clé de 80 bits. Aucune cryptanalyse n'est sortie depuis ce temps. Alors bonne chance pour ta cryptanalyse :)
Quant à Manchester en 2003, il s'était attaqué aussi à démontrer que l'encapsulation en lettres minuscules était simple.
L'encapsulation n'est pas l'algorithme. Ca vous dit quelque chose MIME et UUENCODE ? car ce sont aussi des méthodes d'encapsulation.
Attaquez vous donc à l'algorithme cfc et cfd (la façon dont sont crées ces deux variables) et on en reparlera.
1 sept. 2009 à 06:58
De toute façon je viens de télécharger un bon gros PDF sur la cryptanalyse différentielle de DES, je vais essayer d'y comprendre quelque chose puis on verra :)
"a mon sens plus un algo est complexe plus il est suceptible de contenir des failles auquels l'auteur n'a pas pensées" : +1 ! Effectivement, il ne suffit pas dans un algo de chiffrement de dire "woah j'v'ais ajouter "C := C * Key" ça va renforcer la sécu !!
Il faut se dire "héhé mais qu'est-ce que ça fait si je fais ça ? Oh merde ça permet peut-être une cryptanalyse par mod N, ou encore une attaque rectangle ! Mais ... en faisant "C := (C * Key) or (Key + C)", cela ne devrait pas être possible ... ah ouais mais là une différentielle est possible argh" (evidemment ce ne sont que des exemples, j'ai pas vérifié si ces cryptanalyses étaient effectivement possibles). Regardons par exemple le chiffrement de César. Le principe est il-n-y-a-plus-simple, et il a tenu des années et des années ! Prenons le SHA (algo de hashage) : son principe est supra simple : expandre les 512 bits du bloc de message en 2560 bits de données, obtenues par un passage dans une S-Box, une paire d'opérations logiques et une rotation vers la gauche, puis ensuite effectuer une opération logique des 512 bits du bloc de message avec ces 2560 bits, accompagné d'un échange de données puis d'une rotation de 5 bits vers la gauche ! Inutile de se compliquer la vie avec un algo plus que redondant (voir la fonction Code), un algo lent (voir la fonction Assemble), et surtout un algo mal codé (voir la totalité de la source).
Bref ... voilà. Sinon j'espère que Alexander connaît le principe de Kerchkoff, sinon il n'ira pas loin ... je cite de mémoire : "La sécurité d'un algorithme ne doit pas reposer sur son secret, mais sur le secret de la donnée additionnelle qui permet de faire fonctionner l'algorithme correctement - a.k.a. la ou les clefs).
Cordialement, Bacterius !
PS : je veux devenir cryptologue plus tard, mais je suis un gars :p (cf "une vrai pro de la crypto" :p)
31 août 2009 à 17:50
Biensur que ton reverse ne représente pas une cryptanalyse complete,mais démontre assez simplement l'existance de "failles" qui peuvent par la suite etre exploitées, biensur pas tel quel il faut.
1. Pousser la cryptanalyse bien plus loin.
2. Réaliser un algo de reverse complet qui exploite unmaximum les failles.
Dans ce cas-ci, l'algo n'est pas simple a comprendre, mais ce fait ne le rend pas "hyper sécure", au contraire, a mon sens plus un algo est complexe plus il est suceptible de contenir des failles auquels l'auteur n'a pas pensées.
Quand au graphes différentiels j'en avais faits a l'époque, il demontrent comme je l'ai dit a ce moment-la des similitudes et redondances constantes et donc résversibles.
Bacterius continue sur cette voie tu deviendras une vrai pro de la crypto...
Bon Coding...
ManChesTer.
31 août 2009 à 06:18
Son algo est peut-être "moyennement" sécure, ou encore "high security", ou encore "zero security", seule la cryptanalyse nous le dira. De toute façon, Alexander ne peut pas affirmer que son algo est sécure sans présenter la cryptanalyse sur sa page lycos.
Cordialement, Bacterius !
30 août 2009 à 14:08
Je ne sais pas si l'auteur du source a compris, c'est en gros ce que j'essayais de lui expliqué en 2004 avec d'autre mots et sans donner le détail (on n'est pas la pour aider a la cryptanalyse).
Tu constateras vite que cet algo ne tiend pas face a une vraie cryptanalyse.
Si celle ci est efficace pour les 16 premiers octets, je décrypte donc ces 16 premiers octets, jai maintenant un fichier crypté de taille fichier-16 octets, il me reste a répeter le procesus..., si je veux moins me casser la tete je peux biensur le faire que sur une partie de ses 16 octets... et on a pas encore fais la vraie cryptanalyse...
Quand au brute force, le nombre d'essai peut etre réduit drastiquement.
Ecrire un algo de cryptage est une chose le rendre complexe est simple, mais ca ne veut pas dire que il est sécuritaire. Dailleurs les algos considérés a ce jour comme sécuritaires sont souvent assez simples.
Tout ajout ou modification a un algo de crypt peut le rendre non sécure.
Un des signes qui permet de savoir qu'un algo est difficile a "casser" est de verifier si le résult du cryptage donne une signature dite "blanche". Si c'est le cas et que l'algo est bien écrit, tres souvent il est "acceptablement" sécure.
Bon Coding...
ManChesTer.
30 août 2009 à 08:47
___________________
Evidemment, ceci n'est pas une "vraie" cryptanalyse, elle se contente de casser les petites protections du chiffrement. Il faudrait pour une vraie cryptanalyse, cryptanalyser cfc et cfd ! Je vais m'y pencher. Et c'est là qu'on va véritablement voir si ton algo tient le coup.
Cordialement, Bacterius !
30 août 2009 à 08:19
Premièrement, la clef principale de ton algo (Cle) est sur 16 octets, ce qui représente, en brute-force, 2^128 combinaisons potentielles à tester. Le travail du cryptanalyse est de descendre en-dessous de ce nombre d'opérations. On va voir ce que ça donne ....
Prenons un message Mt, constitué de N octets (caractères), et son équivalent chiffré, Ct, constitué de 2 * N octets (caractères).
Pour chaque double-octet de Ct (puisque chaque octet de Mt conduit à deux octets de Ct), on a :
____________
1) Notons d (PETIT d), la valeur que tu donnes au premier octet que l'on traite (suivant la première instruction case..of). On connaît d très facilement, il suffit d'inverser l'instruction case.
Notons e (PETIT e), la valeur que tu donnes au deuxième octet que l'on traite (suivant la deuxième instruction case..of). On connaît e très facilement, il suffit d'inverser l'instruction case.
2) Notons c (PETIT c) la valeur de l'octet de Mt qui correspond aux deux octets de Ct que l'on traite. J'aperçois dans ton code, juste avant les deux instructions case..of qu'on vient de reverser :
"d:= c shr 4;". On connaît d, on connaît 4, où est le problème ?
c = d shl 4.
3) Bon, on s'approche. Maintenant, on sort des certitudes pour jouer aux devinettes. On constate que c ne subit aucune modification entre "c:= ord(Buffer[j]);" et "c:= c xor (cfc xor cfd);". Il nous reste donc à trouver le 2eme "petit c" de la deuxième instruction, pour retrouver l'octet de Mt. Si l'on note M l'octet non chiffré (de Mt), on a :
c = M xor (cfc xor cfd).
Je me fiche un peu de (cfc xor cfd), je ne prends pas la peine de le cryptanalyser, mais en le faisant on peut peut-être obtenir de meilleurs résultats. Donc, je note X la valeur (cfc xor cfd). On a :
c = M xor X.
Or, nous on cherche M (puisqu'on connaît c) :
M = c xor X.
Il nous reste donc à essayer les 256 combinaisons possibles de X afin de trouver M en fonction de c. Et la longueur de la clef n'a aucune importance.
________________
Résultats :
pour un message Mt de longueur 1 octet (genre "A"), on a 256 (2^8) possibilités. Cela est inférieur à 2^128, la cryptanalyse a réussi.
pour 2 octets, on a 2^8 * 2 possibilités 2^9 512. Cela est inférieur à 2^128, la cryptanalyse a réussi.
etc ...
Ma cryptanalyse ne sert plus à rien à partir d'un message de longueur supérieure à 2^128 / 2^8 octets, soit 2^120 octets (car le brute-force serait plus efficace à ce point). Mais on a le temps de voir venir.
____________________________
Comme quoi il ne suffit pas d'accumuler les lignes de code compliquées pour produire un bon algo. Donc tes "high security" blabla, tu peux les ranger :)
Cordialement, Bacterius !
4 juin 2006 à 16:44
J'ai un petit souci avec le cryptage XOR, j'arrive d'après un mot à obtenir un cryptogramme correct, je me reporte donc à la table ASCII pour convertir en lettre mais je ne sais pas s'il faut écrire les caractère tel quel ou s'il faut encore encoder.
Exemple : Pour "Porte" moi je trouve "3 ETX ETB ETB TAB" mais quand je vérifie mon calcul sur un site prévu pour, il me donne
"3\u0003 \u0017\u0009" Alors je sais qu'il y a un rapport avec l'héxa car soit disant ce sont des caractères qui ne peuvent pas s'afficher mais un autre site me dit que "OK !" après le cryptage, veut dire FF BS b ce sont donc des caractères spéciaux, alors qui dit vrai qui dit faux ? y à t-il une régle bien précise afin que je puisse passer à autre chose "ça fait deux jours que je prends la tête !" Merci d'avance.
2 juil. 2004 à 21:26
ailleurs dans le monde ce n'est pas limité, on peut utiliser du 256 bits.
oui tu peux surchiffrer le resultat de PC1 par un autre algo si tu veux mais ce n'est pas nécessaire au point de vue securité.
2 juil. 2004 à 20:43
23 juin 2004 à 17:35
20 oct. 2003 à 00:32
14 avril 2003 à 20:28
1) Alors déjà je pense qu'il y a une erreur ici :
j:=valeur_hexa;
CodeA:=valeur_hexa and $F;
CodeB:=(Valeur_Hexa shl 8) and $F;
CharA:=chr(65+codeA);
CharB:=chr((CodeA-CodeB)+65);
-> CharB devrait être CharB:=chr(65+CodeB);
je ne vois pas ce que tu fais avec (CodeA-CodeB)+65
2) Ceci dit cela revient EXACTEMENT au même que les cases que j'ai mis dans mon algo.
Si j'ai mis des cases c'etait pour montrer à l'utilisateur que la transformation en lettres n'intervient que comme format d'envoi de messages. La solution que tu proposes est plus rapide que les cases mais offre l'inconvénient d'être plus opaque pour le programmeur (il ne voit pas forcément à quoi sert le +65 s'il n'a pas pas réagit au fait que 65 est le code ASCII de la lettre 'A' en majuscule.
Ceci dit je ne vois pas où se situe le problème de sécurité que tu soulèves??? Il n'y a aucun problème de sécurité à utiliser des cases ou un +65 pour transformer le résultat du code qui se trouve en sous hexadécimale au début et en format lettres à la fin.
3) Ensuite je ne vois pas ce qui te fait dire que mon algo est loin d'être aussi fiable que le DES, il est est aussi fiable à clé égale. Il est même plus fiable que le Triple DES pour la version PC1 à 256 bits.
Tes affirmations pour dire qu'il n'est pas aussi fiable ne reposent sur aucune affirmation concrète : par exemple démonstration en cryptanalyse linéaire ou différentielle.
4) cx:= $015a; <== remplacer par un calcul basé sur le password
bx:= $4e35; <== idem
Justement si ces valeurs sont là c'est pour éviter le biais. Elles disposent d'un poids ternaire élevé et évite la symétrie circulaire. Elles permettent d'éviter les attaques basées sur la symétrie.
Supprimer ces constantes permettraient alors les attaques basées sur la symétrie.
Tu ne m'as pas l'air d'avoir vraiment étudié la cryptanalyse des systèmes modernes.
Le DES que tu cites, disposent justement de constantes et de tables S dont le but est exactement le même.
Ton affirmation "cette routine 'utilisant aucune constantes rèelles, ton alg n'est pas "altèrè"." est une aberration du point de vue mathématique.
5) Je ne vois pas le rapport entre un algo de chiffrement et un portage vers EDI
6) J'aimerais bien savoir sur quoi se base ton hacker pour prouver qu'une liste de constantes chars (les cases dans mon cas) constituent une faille puisque les cases ne sont utilisés que pour une représentation finale des octets chiffrés.
Bon coding à toi aussi :)
14 avril 2003 à 00:17
1) j'essaye pas de faire un systeme d'ataque mais de te faire reflechir sur certaines failles lièes a la conversion Hexa/alphabet lors de cryptage de donnèes...
2) Malheureusement ton algo est loin (et de tres) de la fiabilitè de DES (encore plus de Triple DES). Pourtant ton algo utilise une bonne base, il est juste domage que lors de la conversion Hexa/alphabet tu modifie cette base (sans probablement meme t'en rendre compte) donc voici un exemple pour remplacer ton case. (Tu comprendras que je ne suis pas la pour donner un cours de hack...).
donc je remplacerais le case par :
encodage :
cx:= $015a; <== remplacer par un calcul basé sur le password
bx:= $4e35; <== idem
j:=valeur_hexa;
CodeA:=valeur_hexa and $F;
CodeB:=(Valeur_Hexa shl 8) and $F;
CharA:=chr(65+codeA);
CharB:=chr((CodeA-CodeB)+65);
rep:= Buffer[j];
v1:=ord(rep)-65;
rep:= Buffer[j+1];
v2:=ord((rep+v1)-65);
// reconstitution de la valer hexa depuis v1 et v2
...
inc(j,2);
cette routine 'utilisant aucune constantes rèelles, ton alg n'est pas "altèrè".
ps: lors de la conception d'un de mes algo, et sa conversion vers de la transportabilitè EDI j'ai rencontrè exactement les memes problemes que toi (je diminuais aussi la fiabilitè de l'algo de base) et c'est un hacker qui m'a prouvè qu'en effet le fait d'utiliser une liste de constante de chars constitue une faille.
Maintenant si tu veux, laisse ton algo tel quel mais ne t'etonne pas si certains hackers trouvent rapidement la solusion de dècryptage...
Bon coding ....
ManChesTer.
13 avril 2003 à 01:12
Tu crois que si on trouve une séquence quelconque pour un mot de passe donné, alors on peut appliquer un XOR sur un autre fichier crypté avec le même mot de passe pour le décrypter, ceci en utilisant uniquement la séquence sans même devoir connaître la clé de cryptage.
Ceci peut marcher pour un algo de type Vigenere mais pas pour mon algo.
En admettant que tu recuperes une séquence de ton fichier de 1Mo de zéros, tu ne pourras rien en faire, même si un autre fichier texte est crypté avec le même mot de passe que le fichier de 1Mo, tout simplement parce que l'algo fonctionne en mode OFB (Output FeedBack), c'est a dire que les données précédentes interviennent dans les données suivantes. Ainsi les lettres ne sont pas cryptées indépendamment les unes des autres mais sont interdépendantes.
Pour t'en convaincre crypte une simple suite de AAAAAAAAAAAAAAAAAa
puis insère un B au milieu AAAAAAAAAAABAAAAAAAAAAAAAAAAA
regarde au niveau du cryptage de la deuxième ligne qu'après le B le cryptage change complètement, le B a modifié les relations d'interdépendances dans la suite du cryptage.
Bref ton système d'attaque par séquence ne peut pas marcher dans mon algo tout comme dans plein d'autres algos solides comme le DES ou le Triple DES.
a+
13 avril 2003 à 01:04
Tu as déjà utilisé le DES 56 bits ou le Triple DES 168 bits en mode ECB (Electronic Coding Book) ? Code voir 1Mo de zero avec le DES et tu verras des séquences se répéter, pourtant tu ne peux rien cracker avec cela. Le DES est utilisé dans le domaine bancaire et les grandes entreprises et est extrement fiable surtout pour le Triple DES.
Essaye un changement un octet dans ton méga octet de zéro et regarde comment l'algo se modifie apres cet octet.
Enfin tu ne sembles pas avoir de bonnes notions de crypto.
Toi qui dit que tu peux retrouver une clé sans problème voici une suite de AAAAAAAAAA crypté avec une clé, donne moi donc la clé. De toutes façons tu ne peux y arriver alors ne te fatigue pas.
a+
jadmkknenfbjokelcmkgkcgcbjjogellgmkikgcdlodojglbpecpdombdlfh
jpdjchgfjfcbmafcbbgegddhkfnhaadlblheelibfjeajfbhnbkcphiajjak
kknijkmkmgaglabgldndoamfacoapideehgalkpnkcecmmbngejaneldkcjb
dmbdhjlbgfelofdpfdidfgkephggajpjfldbhgendbbgcbddlphkndnbeppe
gnfcohjehagkiakmhemaeohijjdnpofp
P.S. je travaille aussi dans l'info
11 avril 2003 à 20:24
Je te laisse a tes illusions, dèsolè d'avoir voulu faire avancer le shmilblik en te signalant une faille, mais si tu ne veux pas comprendre ce qu'est un modele rèqurant, libre a toi....
Ps: mon extrai ne viens pas de ta routine de cryptage mais bien de celle de dècryptage, le "mascage" (conversion AscII vers alphabetique permet de retrouvè la sequance de cryptage, si tu ne comprend pas ce que je veux dire utilise un fichier avec des 0 uniquement (1mb par exemple), et tu veras des sequances rèpetitives, les conaisseurs aprècierons...).
D'un autre cotè, si je ne maitrise pas mon domaine, je me demande quand meme comment ca se fait que j'en vis depuis plus de 10 ans maintenant.
Bon coding...
ManChesTer.
11 avril 2003 à 10:53
Désolé mais la partie que tu cites n'est pas l'algo de cryptage. L'algo de cryptage est la partie Assemble() dans mon code.
La partie que tu cites avec les cases permet un affichage du cryptage sous forme de lettres au lieu d'afficher les caractères cryptés sous une forme ASCII comme par exemple : '-|è_'"~°+
ce texte crypté sera remplacé par des lettes abdfplacb, cela permet de faire un copier coller du texte crypté dans un email par exemple.
Le bruteforce est donc necessaire, la partie que tu cites n'etant utilisée que pour l'affichage final, cela revient à un format MIME ou un format UUENCODE pour l'affichage mais n'est en aucun cas le cryptage proprement dit.
On ne peut donc en aucun cas retrouver quoi que ce soit et surement pas la clé en regardant la partie 'case'.
bonne journée
10 avril 2003 à 22:38
Regarde donc ton algo et rèecris le a l'envers, c'est pas trops complexe...., donc un brutefoce n'est pas utile et "10 milliards d'ordinateurs" le sont encore moins....
La thèorie est belle, et en effet le cryptage est sècure (ce que tu prouve) mais si l'algo est rèversible donc ....
C'est ca mes arguments ...
Nb: la partie faible de l'algo est notament les "rep" et sont codage qui est rècurant, il est donc par via les valeurs possible de retrouvè le password qui a servis a l'encryptage.
c'est ici :
rep:= Buffer[j];
case rep of
'a' : d:= 0;
'b' : d:= 1;
'c' : d:= 2;
'd' : d:= 3;
'e' : d:= 4;
'f' : d:= 5;
'g' : d:= 6;
'h' : d:= 7;
'i' : d:= 8;
'j' : d:= 9;
'k' : d:= 10;
'l' : d:= 11;
'm' : d:= 12;
'n' : d:= 13;
'o' : d:= 14;
'p' : d:= 15;
end;
un petit algo pour remplacer ses "case" pourrais largement compliquer le reverse de ton algo.
Bon coding.
ManChesTer.
Ps : ce n'est pas une critique peut d'algo de cryptage "libres" sont aussi bien que le tien ....
25 févr. 2003 à 17:32
2) Non absolument pas, je ne vois pas ce que vous appelez reverse. Si c'est essayer les 2 puissance 128 combinaisons, cela va vous faire quelques millions de milliards d'années à attendre n'en vous déplaise !
3) Encore non, d'une part il n'y a pas de limitation alphabétique. L'exemple dans le source est avec une phrase comme mot de passe, mais on peut très bien donner comme clé un tableau de 16 octets hexadécimaux.
De plus meme si on limitait les 16 caractères à l'alphabet A..Z a..z et 0..9 (ce qui n'est absolument pas le cas dans PC1) on aurait 26+26+10=62 possibilités par octet.
donc pour 16 octets on aurait 62 puissance 16 possibilités=47672401706823533450263330816
En admettant que l'on dispose de 10 milliards d'ordinateurs et chacun de ces ordinateurs fait 1 milliard de test par seconde, on divise le nombre de possibilités par 1 milliards puis par 10 milliards puis par 3600 pour avoir le résultat en heure puis par 24 pour avoir le résultat en jours puis par 365 pour avoir le résultat en années, cela prendrait 151 ans pour casser une clé alphabétique (je ne parle meme pas du cas ou on utilise une clé hexadécimale).
5) Je te propose de traduire l'algo en assembleur, d'acheter 10 milliards d'ordinateurs qui chacun font 1 milliard de test de password par seconde, et on repalera ensuite du fait que l'algo n'est pas 'secure' comme tu dis :)
6) Si on prend une clé hexadécimale comme c'est faisable, on a :
256 possibilités par octet puissance 16 = 3,4028236692093846346337460743177e+38
on tombe alors avec le meme nombre d'ordinateurs que ci dessus à un temps d'attaque de 1079 milliards d'années.
7) Conclusion : tes arguments ne tiennent pas, désolé :)
24 févr. 2003 à 14:04
1) Domage de ne pas avoir traduit l"encrypteur en assembleur ...
2) Suivat ce source, le reverse est simple....
3) Et enfin avec une bonne routine assembleur et un bruteforce, le dècryptage est vite fait a cose de la limitation alphabetique 'A..Z', 'a..z','0..9' qui est dans le source....
Il faudrais don obtimiser legerement l'algo (c'est fesable) et le compliquer lègerement au niveau de la clef pour le rendre plus "sècure".
Bon coding.
ManChesTer.