LEA EN MODE CHIFFREMENT (SEA)

Messages postés
390
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
- - Dernière réponse : Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
- 7 août 2009 à 13:30
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/50321-lea-en-mode-chiffrement-sea

Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
6 -
Bon voilà, alors tout change.
Maintenant c'est un encryptage par flux/bloc, c'est-à-dire que c'est calculé par bloc mais que ça donnerait le même résultat si on faisait octet par octet, c'est juste pour aller plus vite.
Voici le nouveau fonctionnement (ce sont des blocs de 512 bits) :

Encryptage :
1. On génère depuis la clef une signature de 512 bits théoriquement unique à cette clef.
2. On ajoute chaque bit de cette clef à chaque bit du premier bloc du message.
3. On génère depuis la signature précédente, une nouvelle signature 512 bits unique.
4. On ajoute chaque bit de cette clef à chaque bit du second bloc du message.
5. Etc ...

Décryptage : La même chose sauf qu'on soustrait la clef au bloc du message ;)

Propriétés : pour chaque clef, l'algorithme va générer une suite totalement unique de nombres pseudo-aléatoires.

Faiblesses : Si une partie du message ne contient que des bits à 0, et que cette information est rendue publique, alors 0 + Clef = Clef ...

Avantages : Pour pouvoir espérer décrypter le message sans connaître la bonne clef, il faut pouvoir extraire 512 bits de clef correctement placés dans le message AU MINIMUM. Et même en ayant cette information, il ne sera possible que de décrypter les données se trouvant APRES le bloc associé à la clef que l'on vient de trouver.

Cordialement, Bacterius !
Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
6 -
;D
D'ailleurs il faut que je mette à jour LEA-RNG et SEA avec la nouvelle mouture de LEA, tu m'y fais penser ... :p

Cordialement, Bacterius !
cs_cantador
Messages postés
4716
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
10 -
lea et sea sont dans un bateau..sea t.. (lol)
Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
6 -
Bon euh maintenant, c'est la même fonction que ça soit le cryptage ou le décryptage. Des améliorations notables dans l'algorithme :

- même calcul pour le cryptage/décryptage.
- XOR de l'octet avec les 16 octets de la clef, de façon itérative.
- hashage chaîné, chaque clef entraînera théoriquement la génération d'une suite unique de clefs de cryptage.

Pour le hashage chaîné, par exemple, disons qu'on a une clef "1".
1 => 5 => 3 => 2 => 6
2 => 6 => 8 => 9 => ...

Pour éviter les chaînes cycliques (cf. 1 => 2 => 1 => 2 => 1 => ...), on doit faire confiance à l'algorithme de hashage. Depuis sa modification, ses périodes devraient être suffisamment importantes pour assurer un cryptage correct.

Pour plus de questions, posez votre question en commentaire.

Cordialement, Bacterius !
John Dogget
Messages postés
390
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
Je regarde tout ça dés que j'ai réinstallé delphi, j'ai fais un bon nettoyage à mon PC ^^
Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
6 -
Nouvel exemple, qui permet de comparer visuellement le résultat d'un cryptage rapide et sécurisé sur un bitmap. Vous allez vite vous rendre compte que le temps de calcul nécessaire au cryptage sécurisé vaut bien le coup. Cependant pour des petits messages dont le contenu n'est pas trop critique, genre échange de fichiers entre particuliers, le cryptage rapide suffit largement (personne n'ira perdre du temps à décrypter vos fichiers, sauf si vous avez des ennemis ...).

Cordialement, Bacterius !
Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
6 -
Et voilà John, message lorsque l'opération est terminée. Je vais tenter de mieux expliquer le code de cryptage/décryptage.

Cordialement, Bacterius !
Bacterius
Messages postés
3793
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
6 -
Oui, c'est vrai que j'ai principalement testé sur des fichiers de plusieurs centaines de Mo, donc pour voir quand c'était fini suffisait de revenir après le dîner lol. Je tiendrai compte de cela et je mettrai un message "opérations terminées" :)
2eme question : en fait tu voudrais savoir depuis un cryptage si il a été crypté par mode rapide ou non ? Délicat ... voire impossible si l'on ajoute pas un bit de détection à la fin du cryptage ...
3eme question : En gros tu veux crypter le fichier mais aussi son nom ? Pas bête ... mais faudra que ça reste compatible avec le système de fichiers (pas de caractères comme "", ...)

Pour le code, c'est très simple :

P^ = octet avant et après modification
Key.B = 2eme double mot de la clef de 128 bits
Key.B mod $FF on ramène ce double mot sur une opérande d'octet (0..255) $FF 255 [1]
C = 3eme double mot de l'indice de position (un peu compliqué ça)
C mod $FF = on ramène C sur une opérande d'octet
P^ xor (C mod $FF)) = On effectue un xor logique de l'octet avec C ramené sur octet [2]
Pour finir, on xor [1] et [2] (qui sont tous les 2 des octets), et cela devient notre valeur d'octet.

On fait ça 4 fois, 1 fois pour chaque double mot de la clef et de l'indice de position.

Cordialement, Bacterius !
John Dogget
Messages postés
390
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
Ca marche bien ^^

Par contre le code, au secours *_*

P^ := (Key.B mod $FF) xor (P^ xor (C mod $FF)) <- kécé ??!

Au rang des ameliorations, tu pourrais rajouter :
- un message quand les operations sont terminés, avec ton exemple ça va tellement vite que j'ai cru que rien ne s'etait passé
- une detection du mode de cryptage (rapide/pas rapide)
- un cryptage des noms de fichiers (nom + extension)

C'est juste des idées comme ça, j'ai rien compris au code :p