Discussion :

[BiM]

Bonjour,

Je ne fais pas bien la différence entre le chiffrement et la crypto mais je suis obligée de m'y intéresser.

En clair, je dois crypter (ou chiffrer) un fichier efficacement avec une clé privée pour le chiffrer et une clé publique pour le déchiffrer (et non l'inverse ).

Il faudrait que l'algorithme soit encore inviolé (au moins à un certain niveau) et si possible libre d'utilisation.

Bon, j'ai regardé un peu ce qui existait et j'avoue que j'ai du mal à m'y retrouver :

• DES et 3DES : Apparement considérés comme obsolètes, protection trop faible
• Blowfish : Il serait pas mal mais je ne sais pas s'il a une clef publique et une clef privée
• Twofish : Dérivé de Blowfish mais est-il plus fiable ? Quels sont les avantages et les inconvénients par rapport à Blowfish ?
• Rijndael (et AES) : Adopté comme standard. A-t'il été cassé ? Est-il libre ?
• Serpent : Visiblement, il est sensiblement identique à Rijndael mais plus lent.
• Autres ?

Quels sont ceux libres d'utilisation ? Quels sont ceux qui ont une clé différente pour le chiffrement et le déchiffrement ? Quels sont ceux qui ont été cassés et à quel niveau (et ce que cela veut dire) ?

Pour vous aider à répondre dans mon sens, le but de cet algorithme serait de chiffrer un fichier type XML ou autre de licence.

Merci de votre aide !

Webographie :
[PDF] Algorithmes de chiffrement (22/06/2005) Document un peu ancien
[Wiki] Wikipédia, portail cryptologie
(et autres liens du Wikipédia concernants entre autre les algos cités ci-dessus)

[jobherzt]

en fait tu n'as pas 50 possibilités ! les cryptosystemes a cle publique/privé et les symetriques sont foncierement differents et ne peuvent pas etre utilisé l'un a la place de l'autre.

tous ceux que tu cites sont des sytemes syetriques, donc a priori ils ne t'interresse pas (enfin, tout depend de ce que tu veux faire exactement).

les 2 seuls, a ma connaissance, systeme a cle publiques (tous 2 libres de droit, enfin le 2e est un peu plus libre, le premier a ete breveté un temps, mais ce n'est plus le cas crois-je) sont :

- RSA, le plus connu, basé sur la difficulté de factoriser de grands entiers
- elgamal, moins connu mais aussi bien voire mieux (http://fr.wikipedia.org/wiki/Cryptos...8me_de_ElGamal) basé sur la difficulté de calculer des logarithmes discrets...

ne te laisse pas effrayer par le terme de "log discret", ca n'est pas tres compliqué : connaissant 3 entiers g, a et m, il s'agit de retrouver un certain x tel que g^x=a modulo m.

en general le procede que tu decris (chiffre avec la prive, dechiffrer avec la publique) sert a signer un document pour en attester l'auteur. est ce que tu veux faire ? dans ce cas, en general, on ne chiffre pas directement le document (ces algos sont un peu lent, vu qu'ils requiert des calculs mathematiques), mais on chiffre la somme md5 ou sha-1 du document (ce qui va beaucoup plus vite, et suffit a identifier le document formellement). le protocole est le suivant :

- l'auteur calcule le hash (md5 ou SHA) de son document
- il crypte ce hash avec sa cle privé et fournit le document et la signature (eventuellement dans un meme fichier)

- le lecteur caclule aussi ce hash
- il dechiffre la signature grace a la cle publique de l'auteur
- il compare les 2.

[jobherzt]

tiens, au passage : tu pourrais etre interressé (je pense meme que c'est la meilleure solution) par l'algorithme DSA (pour digital signature algorithme) qui est specifiquement concu pour signer des documents en utilisant le meme principe qu'elgamal.

http://fr.wikipedia.org/wiki/Digital...ture_Algorithm

[Janitrix]

Il faut savoir que les algorithmes asymétriques (clé publiques/clé privée) sont plus lents et ne peuvent pas crypter beaucoup de données. Lorsque j'ai débuté la cryptographie avec Java, j'ai été surpris que par exemple, si tu veux crypter un fichier avec RSA, et que tu as une clé de 1024 bits, tu ne pourras pas crypter un fichier de plus de 1024 bits ! Ce qui limite énormément la marge d'utilisation.

Donc, la parade qui a été trouvé est de crypter le fichier avec un algorithme symétrique, relativement sur, et surtout rapide, puis de crypter la clé de chiffrement de cette algorithme avec RSA, algorithme sûr, et sa lenteur n'est pas un problème puisqu'il ne faut crypter que très peu de données (la taille d'une clé de chiffrement).

Plusieurs discussions existent déjà, je te conseille de lire le message de Razgriz, qui est très intéressant.

Bonne chance et n'hésites pas à demander plus de précisions

[jobherzt]

Lorsque j'ai débuté la cryptographie avec Java, j'ai été surpris que par exemple, si tu veux crypter un fichier avec RSA, et que tu as une clé de 1024 bits, tu ne pourras pas crypter un fichier de plus de 1024 bits ! Ce qui limite énormément la marge d'utilisation.

euuuuh, que ces algos soient plus lents c'est indeniable, je l'ai deja expliqué. qu'il y ait une limitation dans la taille du message a chiffrer, ca par contre c'est totalement faux....

et ton protocole est correcte pour quelqu'un qui veut chiffrer un fichier au sens classique. Or il semblerait que BiM cherche plutot un systeme de signature, donc pas besoin de cryptage symetrique. (enfin, on pourrait mais ca ralentirait pour rien..)

[BiM]

Moi et la crypto, ca fait heu... un certain nombre


En fait, le but est de faire un fichier de licence et que ce fichier de licence s'il est modifié manuellement soit invalide. Seulement, le mieux serait de ne même pas pouvoir le modifier ni de pouvoir le lire avec un éditeur de texte par exemple.

Donc l'idéal serait de conserver les propriétés suivantes :

• Confidentialité
• Intégrité
• Authenticité

Le fichier initial (en XML ou texte) contient des données du type date de validité et différentes propriétés de limite d'utilisation du logiciel (en J2EE). Il est crypté avec une clef privée pour éviter que le client génère lui-même une licence valide et décrypté avec une clef publique pour que le logiciel puisse en lire le contenu.

Que me conseillerais-tu ?

à toi

[EDIT]Entre temps, j'ai lu les 3 derniers messages Je vois ca après manger.[/EDIT]

[jobherzt]

C'est bien ce que j'avais compris, dans ce cas le DSA me semble vraiment approprié, comme je te l'expliquais c'est justement fait pour authentifier un document, et qui dit authentifier dit evidemment preserver l'integrité..

donc c'est exactement ce que tu decris, chiffrer avec une cle privée, dechiffrer avec la cle publique. sauf que comme je te le disais le mieux est de chiffrer un hash du fichier plutot que le fichier lui meme, c'est tout aussi secure et beaucoup plus rapide.

[Janitrix]

J'avais mal compris, mais pour l'histoire de RSA et la taille des fichiers, j'avais trouvé un document de Sun qui disait qu'on ne pouvait pas crypter un fichier si la taille de ce fichier était plus grande que la clé, cela ne marchait tout simplement pas. C'est peut être seulement avec Java.

Sinon, bah bonne chance BiM

[jobherzt]

J'avais mal compris, mais pour l'histoire de RSA et la taille des fichiers, j'avais trouvé un document de Sun qui disait qu'on ne pouvait pas crypter un fichier si la taille de ce fichier était plus grande que la clé, cela ne marchait tout simplement pas. C'est peut être seulement avec Java.

Sinon, bah bonne chance BiM

en fait avec RSA (comme avec n'importe quel autre systeme symetrique ou assymetrique) on ne peut crypter qu'un bloc d'une certaine taille... mais pour crypter un gros fichier, il suffit de le decouper en bloc et de crypter chacun des blocs !!! et ca fonctionne pareil avec les sytemes symetriques, il y a meme des routines pour modifier la cle a chaque bloc ce qui peut renforcer encore la secutité..

[Janitrix]

mais pour crypter un gros fichier, il suffit de le decouper en bloc et de crypter chacun des blocs !!!

J'avais déjà essayé quelque chose comme ça, mais ça avait rien donné, surement une erreur dans ma méthode. Merci de la précision, je n'étais pas sûr

[jobherzt]

J'avais déjà essayé quelque chose comme ça, mais ça avait rien donné, surement une erreur dans ma méthode. Merci de la précision, je n'étais pas sûr

je ne sait pas si ca vient de la, mais il faut penser a completer le fichier par des données nulles pour que ca tombe rond, et en profiter pour stocker le nombre et la taille des blocs

[Janitrix]

Ah bon, bin je ne faisais rien de tout ça, merci de la précision

Désolé BiM, j'ai détourné la discussion, j'espère que tu as eu ta réponse

[BiM]

Merci pour toutes vos réponses !

En fait, j'ai quelques questions sur le RSA.

Il n'est visiblement plus breveté (depuis septembre 2000), est-ce vrai ? http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman
Donc il serait libre d'utilisation. Mais il me semble qu'il y a des lois en France qui interdise le cryptage RSA au dessus de X bits pour éviter de crypter des messages terroristes. Cependant, j'ai lu (compris), toujours sur le Wikipédia, qu'actuellement (http://fr.wikipedia.org/wiki/Cryptage#En_France) tout moyen et niveau de cryptage est possible. Est-ce vrai ?
De plus il me semble que les clefs 1024 bits sont vulnérables et les clefs 2048 sont sur le point d'être cracké (j'ai peut-être un puissance 2 d'avance sur mes paroles ).

Ensuite sur le DSA, si j'ai bien compris, c'est un algorithme de signature qui repose sur ElGamal ? Quelle est sa résistance aux attaques ?
De plus, il est visiblement breveté (http://fr.wikipedia.org/wiki/Digital...ure_Algorithm), en tout cas aux Etats-Unis.

Ce logiciel est destiné à la vente dans le monde (y compris USA), on ne livre pas l'algorithme de cryptage mais seulement celui de décryptage. Le client ne doit pas pouvoir trouver l'algo de cryptage en décompilant les sources.

C'est le problème du hashage, c'est qu'il faut que le client est aussi l'algo de cryptage. Le client ne doit pas pouvoir m'imiter.

[jobherzt]

alors :

Merci pour toutes vos réponses !

de rien

Il n'est visiblement plus breveté (depuis septembre 2000), est-ce vrai ? http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman

autant que je sache, oui.

Donc il serait libre d'utilisation. Mais il me semble qu'il y a des lois en France qui interdise le cryptage RSA au dessus de X bits pour éviter de crypter des messages terroristes. Cependant, j'ai lu (compris), toujours sur le Wikipédia, qu'actuellement (http://fr.wikipedia.org/wiki/Cryptage#En_France) tout moyen et niveau de cryptage est possible. Est-ce vrai ?

pas tout a fait, il y a des logiciels qui sont homologués. mais la loi est assez flous, surtout dans ton cas ou tu n'utilises pas le cryptage pour proteger des donées sensibles mais simplement comme procede de signature, je pense qu'il n'y a aucun probleme.

De plus il me semble que les clefs 1024 bits sont vulnérables et les clefs 2048 sont sur le point d'être cracké (j'ai peut-être un puissance 2 d'avance sur mes paroles ).

euh, oui, ya de la marge encore, avec 1024 faut deja se lever de bonne heure....

Ensuite sur le DSA, si j'ai bien compris, c'est un algorithme de signature qui repose sur ElGamal ? Quelle est sa résistance aux attaques ?

bah c'est du costaud

De plus, il est visiblement breveté (http://fr.wikipedia.org/wiki/Digital...ure_Algorithm), en tout cas aux Etats-Unis.

bizzare, c'est celui qui est utilisé par pas mal de logiciels libres. enfin peu importe, je pense que les 2 sont libres.

Ce logiciel est destiné à la vente dans le monde (y compris USA), on ne livre pas l'algorithme de cryptage mais seulement celui de décryptage. Le client ne doit pas pouvoir trouver l'algo de cryptage en décompilant les sources.

C'est le problème du hashage, c'est qu'il faut que le client est aussi l'algo de cryptage. Le client ne doit pas pouvoir m'imiter.

alors la je ne te suis plus, mais alors plus du tout... l'important pour pouvoir generer un faux fichier c'est de posseder la CLÉ !! le fait de savoir quel est l'algorithme utilisé n'a absolument aucune importance. donc je persiste, le SHA reste la meilleure solution (j ete rappelle que tu n'utilises pas QUE le sha, mais que tu crypte le resultat avec ta cle privé que tu es seul a connaitre, donc pour fabriquer un faux c'est pas gagné )

donc encore une fois, il est bien evident que dans les differentes solutions que je te propose (SHA + (elgamal, RSA ou DSA)), l'utilisateur n'a aucun moyen de t'imiter.

[BiM]

Bon, tu vas te dire "Wahou cette modo, elle a vraiment du mal" ... ben oui c'est vrai

Alors, tu vas te répéter mais au moins tu pourras te dire que tu m'auras beaucoup aidé.

Procédure à suivre :

1. Je hash le fichier avec sha1 ou sha2 ou avec md5, jusque là, je me porte bien.
2. Je crypte le hash avec une clef privée avec ElGamal, RSA ou DSA, ca va toujours.
3. Je les combine dans un même fichier, comment dois-je faire ?
4. Et comment dois-je faire la comparaison ? Je sépare les fichiers ? Ensuite, je hash le fichier avec le même algo (donc sha1 ou sha2 ou md5) ? Puis je décrypte le hash grâce à la clef publique ? Et je les compare ?

Et comment puis-je faire tout ça ?

[jobherzt]

3 suffit que tu les mettes l'un a la suite de l'autre, mais ca n'est pas du tout une obligation, tu peux tres bien les séparer !!

4 exactement. note que ceci suppose qu'il n'y ait pas moyen de traffiquer non plus la clef publique, il ne faut pas qu'un mechant puisse mettre la sienne a la place.. mais ca quel que soit le systeme employé ca va te poser probleme.

[BiM]

3 suffit que tu les mettes l'un a la suite de l'autre, mais ca n'est pas du tout une obligation, tu peux tres bien les séparer !!

4 exactement. note que ceci suppose qu'il n'y ait pas moyen de traffiquer non plus la clef publique, il ne faut pas qu'un mechant puisse mettre la sienne a la place.. mais ca quel que soit le systeme employé ca va te poser probleme.

D'accord.

C'est là ou est toute la difficulté. Si une personne crypte avec une clef privée à lui et il remplace ma clef publique par la sienne, alors le système ne sers plus à rien. Dans ce cas, y-a-t'il une autre solution envisageable ?

Merci pour ta patience

[jobherzt]

oui et non, c'est toujours le probleme des systemes de signatures numeriques, il faut que la cle publique soit certifiée... si on suppose que ton programme a acces au net il peut rapatrier la cle publique.

sinon, il existe aussi des procedes plus recents qui permettent de fabriquer une cle a partir d'une information nominative sur quelqu'un (son email par exemple) mais la encore ca demande une connection internet.

[BiM]

oui et non, c'est toujours le probleme des systemes de signatures numeriques, il faut que la cle publique soit certifiée... si on suppose que ton programme a acces au net il peut rapatrier la cle publique.

sinon, il existe aussi des procedes plus recents qui permettent de fabriquer une cle a partir d'une information nominative sur quelqu'un (son email par exemple) mais la encore ca demande une connection internet.

Y'aurait eu une connexion internet on aurait fais beaucoup plus simple. Mais il s'avère que l'ordinateur qui contrôle la clef est dans très peu de cas connecté à Internet donc ça tombe à l'eau

[sovitec]

Y'aurait eu une connexion internet on aurait fais beaucoup plus simple. Mais il s'avère que l'ordinateur qui contrôle la clef est dans très peu de cas connecté à Internet donc ça tombe à l'eau

Ca n'a pas grand chose à voir avec l'algorithmique, mais il ne faut pas oublier que souvent le plus simple pour un "pirate" est de modifier l'exécutable pour qu'il saute l'étape de vérification.