Discussion :

[-4ian-]

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 !

[Goten]

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.

[deadalnix]

AES, ou RC4, c'est simple, l�ger, efficace, et encore solide.

[gl]

Sinon un xor c'est sur... si ta passphrase est aussi longue que la chaine a craqu�e.

Et � usage unique

[Jenna]

Est ce que la fonction de chiffrement doit �tre r�versible ? Sinon, il y a MD5.

[droggo]

Goa,

Est ce que la fonction de chiffrement doit �tre r�versible ? Sinon, il y a MD5.

Elle doit l'�tre, sinon on ne parle pas de chiffrage.

[Jenna]

Elle doit l'�tre, sinon on ne parle pas de chiffrage.

On parle bien du chiffrement des mots de passe et pourtant ce n'est pas r�versible.

[deadalnix]

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.

[Jenna]

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.

[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.

[Jenna]

Chiffrer, c'est stocker l'info de telle mani�re qu'elle ne soit pas intelligible.

D'accord sur ce point.

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 !

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.

Comme quoi il est possible de rendre incompr�hensible de l'information sans pour autant utiliser une fonction r�versible.

Parler de chiffrage dans un tel cas est bien un abus de langage, et c'est totalement incorrect.

Chacun sa sensibilit�, moi, cela ne me choque pas (dans le contexte que je d�cris)

[ctxnop]

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

[ctxnop]

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

[deadalnix]

Comme quoi il est possible de rendre incompr�hensible de l'information sans pour autant utiliser une fonction r�versible.

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).

[-4ian-]

Merci pour vos r�ponses ( et pour le petit d�bat ), je me suis tourn� vers l'AES

[Goten]

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).

hein? Une infinit� ? justement le principe du hash c'est d'�viter les collisions ...

[deadalnix]

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�.

[ctxnop]

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 D'ailleur je m'en vais me renseigner sur cette histoire du paradoxe de l'anniversaire, ca a l'air int�ressant )

[Goten]

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�.

Je sais bien tout �a, c'est juste que j'avais mal interpr�t� ce que tu voulais dire. (les joies de lire vite...)

[koala01]

Salut,

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 D'ailleur je m'en vais me renseigner sur cette histoire du paradoxe de l'anniversaire, ca a l'air int�ressant )

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.

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.