Version imprimable
Bonjour,
je suis à la recherche d'une implémentation d'un algorithme de cryptage. Seulement, j'aimerais autant qu'elle soit légère ( En évitant une bibliothèque entière dédiée à ça ), simple ( -> Utilisation facile avec des std::string, ou au moins un exemple avec ), sûre ( Algorithme reconnu, pas un simple XOR ) et portable.
Mais j'ai bien l'impression que je demande la lune... A moins que quelqu'un ait la perle rare ?
Merci d'avance !
qui soit pas dédié et sur ... je connais pas. (qui soit pas dédié tout court d'ailleurs je connais pas).
Sinon un xor c'est sur... si ta passphrase est aussi longue que la chaine a craquée.
:mouarf:
AES, ou RC4, c'est simple, léger, efficace, et encore solide.
Et à usage uniqueCitation:
Envoyé par Goten
Est ce que la fonction de chiffrement doit être réversible ? Sinon, il y a MD5.
Goa,
Elle doit l'être, sinon on ne parle pas de chiffrage. :)Citation:
Envoyé par Jenna
On parle bien du chiffrement des mots de passe et pourtant ce n'est pas réversible.Citation:
Envoyé par droggo
Ce n'est parce que beaucoup de gens raconte des âneries qu'elle deviennent vraies pour autant.
MD5, ce n'est pas du chiffrement mais du hachage.
Je suis tout à fait d'accord. Il n'empêche que l'on peut utiliser des fonctions de hachage pour faire du chiffrement non réversible. Les mots de passe dans le fichier /etc/shadow sont chiffrés par défaut avec MD5.Citation:
Envoyé par deadalnix
Non, ce n'est pas du chiffrement. l'utilisation de ce terme est juste incorrect.
Chiffrer, c'est stocker l'info de telle manière qu'elle ne soit pas intelligible. Or, dans le cas du hachage, l'info n'est pas enregistrée (puisque la fonction de hachage n'est pas bijective). C'est complètement différent !
Le hachage permet simplement de vérifier qu'une information source provient du même ensemble qu'un autre. Le nombre d'ensemble étant très grand dans un cas de fonctions comme MD5, cela peut-être utilisé pour les mots de passe.
Mais des fonction de hachage bien plus simples sont utilisés par exemple pour la correction d'erreur (bit de parité sur les liaison RS232, CRC pour les CD ou bien d'autres supports, etc . . .).
Parler de chiffrage dans un tel cas est bien un abus de langage, et c'est totalement incorrect.
Pour s'en convaincre, il suffit de voir qu'une fonction comme modulo x est une (mauvaise) fonction de hachage.
D'accord sur ce point.Citation:
Envoyé par deadalnix
Et pourtant, si on prend l'exemple des mots de passe Unix, la fonction de "transformation" (je ne dis pas chiffrement puisque cela te froisse ;)) est une fonction de hash (souvent, c'est MD5) et c'est l'empreinte qui est enregistrée dans le fichier /etc/shadow.Citation:
Envoyé par deadalnix
Comme quoi il est possible de rendre incompréhensible de l'information sans pour autant utiliser une fonction réversible.
Chacun sa sensibilité, moi, cela ne me choque pas (dans le contexte que je décris)Citation:
Envoyé par deadalnix
En même temps, on ne chiffre pas le mot de passe sous unix, on fait comme partout, on stock un hash, parce que le but n'est pas de stocker le mot de passe, mais de stocker une valeur qu'on pourra identifier.
Stocker le mot de passe est juste intolérable. Ca voudrait dire que si on arrive a entrer sur ton système, on a le mot de passe. C'est une hérésie. Alors que stocker un hash, rentrer sur le système ne donne pas le mot de passe, il faut encore trouver un mot de passe qui donnera le même hash.
Chiffrer n'est définitivement pas la même chose que hasher.
Il est vrai cependant que beaucoup de personnes utilisent le mot "chiffrer" ou "crypter" en parlant des hash, mais c'est un tort. C'est pareil que les gens qui parlent de "routeur" en désignant les "modem-routeur-switch-wifi". Juste parce que du point de vue markerting c'est mieux de dire "routeur" que "modem-routeur-switch-wifi". Du coup, pour la plupart des gens, un routeur c'est un modem avec 4 ports Ethernet en sortie et du wifi, alors que dans cette définition, la partie routeur n'apparait même pas.
Ce n'est pas parce que certains utilisent le mot qu'il est bon pour autant ;)
Avec tout ca on a pas répondu à la question d'origine...
Voila une implémentation simple du blowfish, un chiffrement rapide et de bonne qualité.
http://www.codeproject.com/KB/securi...px?msg=2665930
edit: Ou directement sur le site de blowfish : http://www.schneier.com/blowfish-download.html
Sinon, le AES ici, mais je suis pas sur de la licence (pas regardé en fait ^^').
http://www.lomont.org/Software/Misc/AES/AES.php
L'information n'est pas stockée. Une infinité d'information donnent le même hash. L'information n'est plus la. Elle n'a donc pas été chiffrée. On a bien un truc incompréhensible au final, mais qui ne contient plus l'info originelle (c'est bien pourquoi ce n'est pas bijectif).Citation:
Envoyé par Jenna
Merci pour vos réponses ( et pour le petit débat :aie:), je me suis tourné vers l'AES :)
Citation:
Envoyé par deadalnix
hein? Une infinité ? justement le principe du hash c'est d'éviter les collisions ...
Un hash de qualité à divers attributs. En fonction de ce pourquoi on l'utilises, on en choisira certains au détriment d'autres.
Éviter les collision est une caractéristique recherchée. Mais ce qu'on entend par la, c'est en fait de bien répartir les hachages. En effet, partant d'un ensemble infini vers un ensemble fini, tu aura forcement des collisions. Ce qu'on cherche à faire quand l'on dit que l'on veux éviter les collisions, c'est qu'on fait en sorte que toutes les valeurs hachées aient sensiblement la même probabilité. En effet, plus ces probabilités sont disparates, et plus il se produira de collisions.
L'étude du paradoxe des anniversaires nous montre que, avec une fonction de hachage parfaite, tu as une chance sur deux d'avoir une collision ou plus entre sqrt(N) éléments si le hachage peut prendre N valeurs.
À ce jeu la, la fonction module est excellente par exemple.
Une autre qualité d'un bon hachage est le fait qu'un modification mineure dans le clair donne un hachage complètement différent. C'est une propriété très importante dans le domaine de la sécurité. À ce jeu la, le modulo est nul.
On va aussi chercher à ce qu'il soit rapide à calculer. Cela est capital dans le cas d'un table de hachage par exemple. Par contre, cela n'est pas important en sécurité.
En plus simple, un hash à une taille finie, donc il existe un nombre exacte de hash possible.
Mais un hash se calcul a partir de et n'importe quoi, de n'importe quelle taille.
Donc, pas besoin de démonstration mathématique compliquée pour comprendre qu'il y a une infinité de données qui donneront le même hash, elles seront juste très différentes les unes des autres et n'auront probablement pas du tout la même taille.
(Entre ici et le topic sur le bcrypt on en aura parlé du hash/chiffrement ces deux derniers jours :mouarf: D'ailleur je m'en vais me renseigner sur cette histoire du paradoxe de l'anniversaire, ca a l'air intéressant :ccool:)
Je sais bien tout ça, c'est juste que j'avais mal interprété ce que tu voulais dire. (les joies de lire vite...)Citation:
Envoyé par deadalnix
Salut,Le paradoxe des anniversaires vient du fait qu'il suffit de regrouper 23 personnes pour avoir une chance sur deux de trouver au moins deux personnes ayant leur anniversaire le même jour, et que, avec 53 personnes, les chances sont supérieures à 99 %, alors qu'il y a, pour les années non bissextiles, 365 jours par an.Citation:
Envoyé par ctxnop
Bien sur, ces probabilités sont calculées sans prendre une date de naissance particulière en compte, mais, au niveau des sommes de hashage, nous observons un paradoxe similaire lorsque l'on s'intéresse au nombre de messages dont il faut évaluer les sommes qu'il faut observer pour avoir une chance sur deux (ou plus) d'obtenir une collision.
En d'autres termes, ce paradoxe met en évidence la "facilité" avec laquelle il est possible d'obtenir une collision "sur demande", si l'on ne prend pas en compte une somme de hashage donnée.
Merci de la précision, intéressant tout ca :ccool:
Pour, quand même, répondre à -4ian-, ce qu'il faudrait surtout savoir, c'est si ton souhait est:Dans le premier cas, et selon le niveau de sécurité que dont tu as besoin, MD5, SHA ou les autres peuvent faire l'affaire.
- de disposer d'un moyen "rapide" de "comparer" deux chaines afin de s'assurer qu'elles sont identiques (ou non) ou
- de disposer d'un moyen de stocker tes chaines de manière illisible, en étant en mesure de récupérer la chaine d'origine "à la demande"
Dans le second cas, il faut bel et bien se tourner vers AES, blowfish ou, pourquoi pas, une "simple" amélioration du cryptage de Cesar, selon, encore une fois, la sécurisation que tu souhaites obtenir ;)
Cesar, ça craint, c'est super faible face à une attaque statistique.Citation:
Envoyé par koala01
Ouais mais bon, quand tu veux juste rendre illisible tes photo de vacances ...
Un pirate se les procures et peu ainsi t'admirer en maillot de bain sur la plage ? Waawww ....
Une protection faible n'est pas forcément mauvaise, tout dépend de ce qui est à protéger. Une protection adaptée à l'intérêt de conserver le secret est souvent plus efficace que de prendre la meilleure sécurité du monde. Ca a tendance a attirer l'attention :aie:
Je sais bien, mais, cela fait partie des méthodes de cryptage ;)Citation:
Envoyé par deadalnix
Il s'agit ( s'agissait ) bien de trouver un moyen de chiffrer une chaine de manière illisible et de pouvoir la décoder ensuite, pas une simple fonction de hash pour vérifier un mot de passe.
Je me suis tourné comme je l'ai dit vers l'AES, j'ai besoin d'un niveau de sécurité élevé, mais je déplore de devoir toujours se "taper" des classes qui utilisent par exemple des char* à tour de bras. En fonctionnement interne, c'est pas mon problème, mais à quand une classe qui définit par exemple
std::string AES::Encrypt(std::string str, std::string password) ?
Sa dépend les sources. (comprendre par qui ça a était codé). Ce genre de chose j'ai l'impression que c'est souvent un wrapper d'un code en C plutôt qu'autre chose... du coup on se tape du C/C++ à tout les étages.
qu'on me fasse pas dire ce que j'ai pas dis : y'a aussi de très belle implémentation hein...
Avoir un algorithme qui est implémenté en C ne me dérange pas, c'est plutôt le fait que la plupart des sources des algorithmes estampillées "C++" ne proposent qu'une classe qui utilise à foison du char*, du unsigned char * datain, du EncryptBlock ( Du C with classes :aie: ) et on a vite ( très vite ) fait de se planter avec ça.
Proposer ceci peut évidemment être utile à plus d'une personne, mais je pense que certains aimerait aussi des fonctions simples comme évoquée ci dessus.
Le fait est que le char* est, en définitive, le socle commun qui permet, le cas échéant, de crypter autre chose que des chaines de caractères (des valeurs numériques, entières ou non, par exemple).
Il n'est, en effet "pas impossible" que le cryptage des données porte sur... autre chose que des chaines de caractères, et donc, que le recours au "socle commun" s'avère nécessaire.
Evidemment, si on a la certitude de n'utiliser que des chaines de caractères, il peut rapidement devenir contraignant de se *taper* ce socle commun.
Mais rien n'empêche, si, effectivement, tu as cette certitude, de fournir une interface utilisant les chaines de caractères et non le char* ;)
Je ne l'ai pas personnellement utilisée, mais le toolkit keyczar a l'air intéressant :
http://code.google.com/p/keyczar/
Exemple :
Code:
2
3
4
5
Oui, j'avais vu ça, ça correspondait bien à ce que j'avais besoin, mais j'ai failli m'étrangler en voyant que ce n'est pas encore compilable en C++ sous Windows.
Juste pour me situer un peu, j'ai fait un programme de chiffrement de message contenu dans un fichier, j'ai utiliser RSA.
La bibli GMP pour les grand nombre, mais pour ton cas, utiliser RSA avec des petits nombres ca ne te conviendrai pas? et pkoi?
RSA avec des petit nombres, c'est nul. RSA est intéressant si tu y va avec des grand nombres que tu ne peut pas factoriser, sinon, le coté asymétrique ne sert plus a rien.
Sinon, c'est bien d'avoir fait du RSA, mais c'est bête car pour peu que ton claire soit plus grand que ta clef, tu es faible devant les attaques statistiques. RSA, ça sert a crypter les clef d'algo symétriques, type AES par exemple.