ALGORITHME DE CRYPTAGE DE 128 OU 256 BITS : PC1 ENCRYPTION CIPHER

Messages postés
378
Date d'inscription
vendredi 20 octobre 2000
Statut
Modérateur
Dernière intervention
11 décembre 2013
- - Dernière réponse : PhilLu
Messages postés
248
Date d'inscription
lundi 9 novembre 2009
Statut
Membre
Dernière intervention
6 mai 2018
- 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

cs_ManChesTer
Messages postés
378
Date d'inscription
vendredi 20 octobre 2000
Statut
Modérateur
Dernière intervention
11 décembre 2013
-
// Very high security //

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.
cs_alexander
Messages postés
26
Date d'inscription
samedi 22 février 2003
Statut
Membre
Dernière intervention
6 octobre 2005
-
1) Rien ne vous empêche de le traduire en Assembleur :)
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é :)
cs_ManChesTer
Messages postés
378
Date d'inscription
vendredi 20 octobre 2000
Statut
Modérateur
Dernière intervention
11 décembre 2013
-
Lol, vi je dois avoir tord, mdr

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 ....
cs_alexander
Messages postés
26
Date d'inscription
samedi 22 février 2003
Statut
Membre
Dernière intervention
6 octobre 2005
-
Bonjour,

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
cs_ManChesTer
Messages postés
378
Date d'inscription
vendredi 20 octobre 2000
Statut
Modérateur
Dernière intervention
11 décembre 2013
-
Lol, bon,

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.