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.