Cryptage à clé Symétrique
Résolu
evay16
Messages postés
8
Date d'inscription
lundi 5 avril 2004
Statut
Membre
Dernière intervention
31 juillet 2007
-
30 nov. 2006 à 23:02
26gega Messages postés 4 Date d'inscription lundi 3 décembre 2007 Statut Membre Dernière intervention 21 avril 2008 - 21 avril 2008 à 13:45
26gega Messages postés 4 Date d'inscription lundi 3 décembre 2007 Statut Membre Dernière intervention 21 avril 2008 - 21 avril 2008 à 13:45
3 réponses
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
1 déc. 2006 à 02:33
1 déc. 2006 à 02:33
qu'entend tu pas "transmise sur un canal securisé" ?
si tu parle d'un protocol dit "securisé", les transmissions sont deja cryptée et difficilement "crackable".
re-chiffrer les données peu ajouter encore une securitée ... mais, une clef de 10 caracteres (soit 80bits) n'est pas le must pour resister a un brute force ou une cryptanalyse.
minimum ce serait 128 bits ... mieux 256 bits et mieux que mieux 512 bits.
mais la encore, ce n'est pas réellement une question de longeur de clef mais plutot de "soliditée" de l'algorithme.
en effet ... meme un chiffrage a 1024 bits avec un simple XOR circulaire est facilement reversible ...
et ce qu'il faut penser c'est a briser la logique entre chaque iteration avec des facteurs independant et unique pour chaque cryptage.
en gros cela se resume a faire en sorte que si je chiffre :
"bonjour" avec la clef "au revoir"
les valeurs en sortie doivent etre totalement differente de ce second chiffrement :
"ruojnob" avec la clef "riover ua"
il y a plusieurs methode a appliquer dans ce cas :
compression de la donnée entrante
inflation de la clef
application d'operande logique (XOR, NOT)
application d'operateur (+ -)
rotation des bits a gauche ou a droite
inversion des octets
inversion des bits par groupage (par binome, trinome ect...)
insertion de leure
etc ...
compression de la donnée sortante
enfin faut aussi penser qu'on doit pouvoir dechiffrer la donnée reçue ... donc faut que ça soit reversible.
<hr size="2" width="100%" />Croc (click me)
si tu parle d'un protocol dit "securisé", les transmissions sont deja cryptée et difficilement "crackable".
re-chiffrer les données peu ajouter encore une securitée ... mais, une clef de 10 caracteres (soit 80bits) n'est pas le must pour resister a un brute force ou une cryptanalyse.
minimum ce serait 128 bits ... mieux 256 bits et mieux que mieux 512 bits.
mais la encore, ce n'est pas réellement une question de longeur de clef mais plutot de "soliditée" de l'algorithme.
en effet ... meme un chiffrage a 1024 bits avec un simple XOR circulaire est facilement reversible ...
et ce qu'il faut penser c'est a briser la logique entre chaque iteration avec des facteurs independant et unique pour chaque cryptage.
en gros cela se resume a faire en sorte que si je chiffre :
"bonjour" avec la clef "au revoir"
les valeurs en sortie doivent etre totalement differente de ce second chiffrement :
"ruojnob" avec la clef "riover ua"
il y a plusieurs methode a appliquer dans ce cas :
compression de la donnée entrante
inflation de la clef
application d'operande logique (XOR, NOT)
application d'operateur (+ -)
rotation des bits a gauche ou a droite
inversion des octets
inversion des bits par groupage (par binome, trinome ect...)
insertion de leure
etc ...
compression de la donnée sortante
enfin faut aussi penser qu'on doit pouvoir dechiffrer la donnée reçue ... donc faut que ça soit reversible.
<hr size="2" width="100%" />Croc (click me)
evay16
Messages postés
8
Date d'inscription
lundi 5 avril 2004
Statut
Membre
Dernière intervention
31 juillet 2007
1 déc. 2006 à 14:43
1 déc. 2006 à 14:43
Merci pour cette explication bien instructives , j'appel ici "canal sécurisé" une lisaisons réseau VPN
Bonne continuation.
Bonne continuation.
26gega
Messages postés
4
Date d'inscription
lundi 3 décembre 2007
Statut
Membre
Dernière intervention
21 avril 2008
21 avril 2008 à 13:45
21 avril 2008 à 13:45
merci.........................2008