Générateur de clés pour VPN

[alexfozzy]

Salut, <BR> <BR> <BR> <BR>Je recherche des générateurs de clés : <BR> <BR>- 3DES <BR>- SHA-1 <BR> <BR> <BR>pour le MD5 j'ai trouvé cette solution, pas tres academique je vous l'accorde, qu'en pensez vous : <BR> <BR><!-- BBcode auto-mailto start --><a href="mailto:alex@minifozzy:~$">alex@minifozzy:~$</a><!-- BBCode auto-mailto end --> <!-- BBCode Start --><B>ps aux | md5sum</B><!-- BBCode End --> <BR> <BR>le resultat par exemple : e9ad8194810307c228707cbca7b42e66 <BR>c'est donc une clé valide MD5. <BR> <BR> <BR>Si vous avez d'autres solutions si simple pour le 3DES ou le SHA-1 je suis preneur <IMG SRC="images/smiles/icon_smile.gif"> <BR> <BR>Alex

[tomtom]

pour generer les cles le plus simple est encore d'utiliser les keygen fournis avec tous les softs faisant de la crypto (ssh-keygen, ipsec newhostkey ...) <BR> <BR>En general, ces softs creent une cle pour du cryptage en 3des. <BR> <BR>Mais j'ai l'impression que tu fais quelques confusions..... <BR> <BR>Il y a deux grands courants dans la crypto : <BR> <BR>le chiffrement asymetrique et le chiffrement symetrique. <BR> <BR>- Asymetrique : Necessite l'usage de deux cles : une pour crypter et une pour decrypter. Les deux clés sont liées par une fonction mathématique complexe, et il est (dans un temps humainement raisonnable) impossible de deuire l'une de l'autre. <BR>Une des deux clés est appelée "cle publique". On la distribue à toutes les personnes devant nous envoyer des messages chiffrés. Tout texte chiffré avec la clé publique ne peut etre dechiffré que par l'autre clé : la "clé privée". Cette clé ne doit être connu que de soi seul, car elle permet de dechiffrer tous les messages chiffrés avec notre cle publique. Si on peut garantir que la clé publique que l'on fournit est bien la notre, alors le possesseur de notre cle publique a la garantie que l'on est le seul à pouvoir dechiffre son message. <BR>Exemple : je suis Banque et je genère une clé privée et une cle publique. Je distribue la cle publique à mes clients. Si ils chiffrent leurs transactions avec cette clé, ils ont la garantie que je suis le seul à pouvoir dechiffrer, à condition d'etre surs que la clé publique qu'ils ont est bien la mienne ! <BR>L'algorithme le plus utilisé au monde pour generer des paires de clefs est RSA. C'est ce qui sera utilisé dans la plupart des cas pour un VPN. On genere des cles RSA avec ssh-keygen par exemple, ou avec ipsec newhostkey. <BR> <BR>- Symetrique. Cette fois, il n'y a qu'une seule clé. Elle est utilisée à la fois pour coder et pour decoder. On sent tout de suite le problème : Si la clé est interceptée lors de la remise au partenaire, alors toute la securité est mise en danger. La distribution de la clé est l'etape cruciale pour la securité du systeme. <BR>Le plus connu des algorithmes de chiffrement symetrique est DES (et sa variante forte 3DES). Il commence à être remplacé par le nouveau standard americain, AES, mais on le trouve encore beaucoup. Pour générer une clé utilisable par 3DES, il suffit de generer une suite aléatoire de caractères ! (la longueur maximale autorisée en france sans declaration est 16 caractères, soir 128 bits, voir post de Antolien à ce sujet...). Personnellement, j'utilise la methode fournie par le man vpn : <BR>#openssl rand 16 | hexdump -e '20/1 "%02x"' <BR>Il y a plein d'autres moyens de faire ça......Un pas si mauvais consistant à taper soi-même 16 caractères <IMG SRC="images/smiles/icon_smile.gif"> <BR> <BR>Ensuite tu parles de clés SHA-1 et MD5.... Il n'y a pas de clés pour ces fonctions... <BR>MD5 et SHA-1 ne sont pas des fonctions de chiffrement mais des fonctions de hachage. Elles sont utilisées pour obtenir une empreinte "unique" (je mets entre guillemets car ce n'est pas tout à fait vrai. Mais la probabilité de generer 2 hashcodes identiques est negligeable). <BR>On utilise par exemple souvent sha1 pour authentifier un texte long... <BR>Exemple : authentification de l'expediteur d'un mail et verification de l'integrité : <BR>La signature d'un email est constituée en calculant un hashcode du message, puis en encryptant ce code avec sa clé privée. <BR>Le destinataire decrypte le message avec la clé publique correspondante, calcule lui aussi le hashcode du message et compare les deux. Si il n'y a pas egalité, le message a ete modifié ou les cles ne correspondent pas. <BR> <BR>On sent encore qu'il est important d'etre sur de la provenance de la clé publique. Un moyen pour ça consiste à les faire delivrer par des autorités de certification. On parle alors de certificats (ex x509) mais ceci est une autre histoire ! <BR> <BR> <BR>Voila, j'espère ne pas avoir ete trop long et avoir clarifié un peu les choses... <BR> <BR>T.