LEA EN MODE CHIFFREMENT (SEA)
John Dogget
Messages postés
384
Date d'inscription
vendredi 18 juin 2004
Statut
Membre
Dernière intervention
7 mai 2009
-
17 juil. 2009 à 01:56
Bacterius Messages postés 3792 Date d'inscription samedi 22 décembre 2007 Statut Membre Dernière intervention 3 juin 2016 - 7 août 2009 à 13:30
Bacterius Messages postés 3792 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
https://codes-sources.commentcamarche.net/source/50321-lea-en-mode-chiffrement-sea
7 août 2009 à 13:30
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 !
5 août 2009 à 23:27
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 !
5 août 2009 à 19:55
2 août 2009 à 22:26
- 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 !
18 juil. 2009 à 16:25
17 juil. 2009 à 22:50
Cordialement, Bacterius !
17 juil. 2009 à 15:02
Cordialement, Bacterius !
17 juil. 2009 à 02:06
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 !
17 juil. 2009 à 01:56
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