Bonjour à tous, je suis en classe préparatoire scientifique, deuxième année MP.
On a des TIPE à faire cette année comme la précédente, sauf que cette fois c'est sérieux.
Adorant l'informatique, j'ai pensé à un TIPE sur la cryptographie, j'aurai donc Math. + Info. J'ai pensé à intégrer de la physique avec la cryptographie quantique mais je ne sais pas comment ça fonctionne...
Pensez-vous que c'est un sujet correct par rapport au thème de cette année : "transfert, échange, flux, correspondance, relation" ?
Sinon a la compression de données, aussi mon professeur m'a dit, mais je pense que c'est mieux d'avoir un sujet qui fait intervenir des maths, de l'info et de la physique, bref, les trois matières de TIPE en MP... ?
Merci d'avance.
Bonjour,
très bon sujet,
aussi bien la compression de données que la cryptographie
reste que si tu veux mettre de la physique là dedans la crypto quantique me semble seule à même de tenir ce rôle, mais "c'est pas simple" !
tu peux aussi (parce que en crypto on a besoin de générateurs de nombres aléatoire) citer les processus physiques qui génèrent du hasard "fort" contrairement au "pseudo hasard" généré par programme
des processus physiques qui génèrent "du bruit" il y en a des tas, tu peux aussi parler de systèmes chaotiques à l'occasion.
Bonjour,
Alors, pour la crypto quantique, c'est très simple, puisqu'il s'agit de réseaux euclidiens.
Je te conseille :
- le cours de Damien Sthelé : http://perso.ens-lyon.fr/florian.hatat/lattice/cours.pdf
- la thèse de Phong Nguyen : ftp://ftp.di.ens.fr/pub/users/pnguyen/PhD.pdf
Après tu peux faire de la cryptanalyse avec les réseaux.
Pour la compression de données, pourquoi pas. Mais la théorie des codes serait peut-être plus propice.
Sinon oui, pour les TRNG, tu peux parler de la source d'entropie de ton générateur.
Sinon, une autre chose qui mélange maths + info + physique :
L'injections de fautes (ou attaques par canaux cachés) dans des composants électroniques qui font tourner des cryptosystèmes.
Tu as les maths avec la crypto, l'info embarquée et la physique des lasers ou d'autres techniques de perturbation ou d'observation.
On n'est plus sur de la cryptologie.
oui, le vocabulaire employé par GavinMagnus est assez hermétique
on se demande bien ce que ça veut dire...
Le vocabulaire, ça va. Mais dire "la crypto quantique, c'est les réseaux euclidiens", cela a autant de sens que dire "la crypto classique, c'est la factorisation/le log discret".
mouais, exemple
Disons qu'une machine quantique est différente d'une machine de Turing.
Un TRNG == True Random Number Generator
La source d'entropie c'est ce qui va te permettre de faire en sorte que le "hasard" de ton RNG soit du "hasard".
Après je fais l'analogie crypto quantique avec les réseaux Euclidiens pour cadrer théoriquement le sujet.
Bref, pour revenir au sujet, il me paraît difficile de mettre des maths, de l'info et de la physique dans un sujet orienté crypto sans faire quelque chose qui deviendra vite trop vaste et donc difficilement gérable.
Si tu veux vraiment mettre les trois à la fois, un sujet dans le domaine du calcul scientifique ou de la modélisation serait sans doute plus approprié... Et encore, ça sera plus de la programmation que vraiment de l'informatique.
Re bonjour, je vois que ce sujet intéresse pas mal de monde^^
Alors j'ai déjà travaillé en C++ (passe temps en fin collège et jusqu'à la 1ère) sur un chiffreur de substitution (XOR) et par décalage (César) multi clé (chaque caractère du message à chiffrer à sa clé propre de décalage).
J'aimerai savoir s'il ne serai pas possible de travailler en priorité sur le chiffrement AES, je m'y intéresse beaucoup car il y a pas mal de calculs je crois et je pense que dans les précédents sujets, les élèves se sont arrêtés au RSA (à me confirmer ?).
Ensuite, pour l'aspect clé de chiffrement, je pourrai parler du caractère aléatoire qui est un gros problème en informatique, notamment avec les bruits dont vous avez parlé plus haut^^...
Donc en résumé, je m'intéresse en majorité à l'AES car il y a des maths à ce que j'ai vu, je pense que peu de monde l'a traité (contrairement au RSA), encore une fois il faudra me confirmer + le caractère aléatoire des clés.
Je pense que l'AES étant d'après ce que j'ai lu l'algorithme de chiffrement le plus puissant au monde, et ayant une vitesse de chiffrement rapide (contrairement au RSA..), je pense que ça peut accrocher du monde un sujet comme ça ?...
Après je ne m'y connais pas vraiment, j'attends vos avis
Bonjour,
Pour l'AES : http://www.cs.bc.edu/~straubin/cs381-05/blockciphers/rijndael_ingles2004.swf
Y'a aussi des papiers qui parlent de l'AES avec des courbes elliptiques :
http://www.cs.bris.ac.uk/~tillich/pdf/Tillich2005AcceleratingAESUsing.pdf
Et enfin, un papier certes de cryptanalyse, mais qui te donne une déf mathématiques des cryptosystèmes à base de substitution, permutation :
http://faculty.washington.edu/manisoma/ee540/Piret.pdf
AES est un algo de chiffrmeent symétrique. C'est totalement différent des algos asymétriques comme RSA, à la fois dans le principe et dans le mode de fonctionnement. En pratique, les deux sont utilisés conjointement. Donc première chose : une phrase comme
C'est reçu, je vais lire les documents que vous m'avez donné.
Au sujet de ce que j'ai dit, c'est juste l'impression que j'ai vu, par contre j'ai vraiment lu sur internet que l'AES était le meilleur algo. de chiffrement.
Mais effectivement, on ne peut pas dire qu'il y en ai de meilleur que d'autres, tout dépend des situations.
Mais une problématique sur un sujet comme celui-ci, visant à intégrer de la physique juste en parlant de la génération des clés aléatoires par bruit de composants électroniques ou autre, ça serai quoi à peut près ?
Même, je me demande si en appliquant un XOR au fichier chiffré par AES, en utilisant une clé de VERNAM (clé de la même taille que le fichier donc pas de répétition, etc...), est-ce que ça ne serai pas une sécurité suplémentaire ? Biensûr, cette clé aussi générée par bruit, etc.. aléatoirement.
N'oublie pas que la clé dans un chiffrement symétrique doit être connue des deux parties. Générer des clés aléatoires, on sait faire. L'échange des clés, par contre, est un problème majeur en crypto.
Le chiffrmeent de Vernam offre une sécurité parfaite, alors tu penses bien que si on pouvait, on n'utiliserait que ça. Une problématique intéressante serait d'étudier toutes les raisons qui font qu'on ne peut pas l'utiliser en pratique à grande échelle.
Si tu veux vraiment de la pysique, je pense que les attaques par canaux auxiliaires seront plus aisées à traiter que le bruit aléatoire pour la génération de clés. En tout ça s'intègrera plus facilement à une étude générale d'un cryptosystème, tu pourras en parler quand tu décriras les attaques qui peuvent être faites dessus.
D'accord c'est reçu.
Donc effectivement en matière de chiffrement symétrique le transfert de clé est un véritable problème...
Je ne sais pas si on aura une solution de suite, ce n'est vraiment pas intuitif en tout cas...
Je pourrai parler de ça, de toute façon ça me fait des pistes en plus à analyser.
Alors là c'est très intéressant ! Quelque chose que je pourrai aborder dans mon sujet.
Je suis content d'avoir la confirmation qu'un simple XOR (ou autre système de décalage de caractère binaire où chaque caractère a une valeur de décalage qui lui est propre) avec une clé VERNAM est "parfait", ou alors il faudrait une attaque par force brute... soit 2^taille message chiffré à tester ça devient vite très grand... même avec 1 MO = 1024 octet on a 2^1024 cas à tester... sans compter la cohérence du message etc... il se peut bien que le message chiffré soit incohérent, un code, numéro, etc... bref...
Donc ça serai intéressant à aborder, cette sécurité "idéale".
Ensuite, pour l'utilisation d'une clé VERNAM à grande échelle, par exemple si on veut chiffrer 100MO de binaire, la clé fera 100MO, tu parles de difficultés à transférer cette clé vu ça taille je pense ? On revient encore au problème de transfert de clé malheureusement...
C'est noté pour les attaques par canaux auxiliaires.
Je vais comparer avec la méthode des bruit pour voir ce qui sera plus flexible à étudier car 10 minutes d'oral ça passe vite, surtout quand on est absorbé par un sujet qu'on aime
C'est reçu merci beaucoup Bachstelze !
Je vais revenir pour la suite ici si j'ai besoin de conseils ou si j'ai des questions !
Bonjour,
à noter quelques petites imprécisions dans le morceau deja dit :
Oui mais ici on parlait du chiffrement de Vernam par rapport aux autres chiffrements symétriques (enfin c'est comme ça que je le comprends). Le problème "si on peut transmettre la clé, autant transmettre le message directement" est valable pour tous les chiffrements symétriques. Il n'empêche qu'en pratique on utilise AES (ou RC4, ou Camellia, ou...), et pas Vernam.
D'accord c'est reçu^^
Pour le 1MO = 1024 octet en parlant du chiffrement symétrique avec une clé VERNAM, pourquoi éviter ce "lapsus".
C'est pour que je sache quelles erreurs je dois éviter de faire, c'était juste pour donner un ordre de grandeur (2^1024 cas à tester en force brute je crois) pour pouvoir embrayer sur le problème de transfert de clé qui ^fait que le VERNAM n'est pas utilisé à grande échelle justement, etc...
Trouver une suite dans tout ça.
Là concrètement je suis en train de réfléchir à un nom pour le TIPE et à une problématique par rapport aux informations que j'ai déjà.
parce que 1Moctet = 1 mega octets ça ne fait pas 1024 octets = 1 kilo octet.
et 1024 octets ça fait 8x1024 bits et donc 213 = 8192 bits
et donc une quantité de messages possibles de 28192
et 1 kilo octets ç'est un "petit" message (environ une page de texte brut)
Par contre, personne n'a relevé
Re bonjour, j'ai réfléchi à tout ceci et lu un peu les liens que vous m'avez envoyé.
Sachant que le TIPE dure 10 minutes pour l'exposé, je n'aurai pas le temps de rentrer dans trop de détails.
Donc introduction sur la crypto. en général avec définition.
Ensuite je vais parler de l'AES car c'est une algorithme de chiffrement qui m'intéresse, qui est le standard de chiffrement aujourd'hui. Je vais donner une idée de sa puissance, en donnant les ordres de grandeur monstrueux, qu'il faudrait plus de temps que l'âge de l'univers pour déchiffrer, etc., pour attirer l'attention.
Ensuite explication du fonctionnement, en mathématique "dures ?"... c'est là que ça sera un peu délicat mais bon, je vais voir.
Je vais ensuite parler du chiffrement VERNAM, avec le simple XOR et dire que si la clé fait la même taille que le message, la sécurité est idéale si je peux dire, je cite mathafou plus haut : "1024 octets ça fait 8x1024 bits et donc une quantité de messages possibles de 2^8192", qui n'est pas acceptable par force brute...
Tout ceci pour arriver au problème de clé avec la transmission et tout : la clé doit être connue des deux partis, etc., elle peut être lourde si on chiffre quelque chose d'une grande taille notamment.
A partir d'ici je vais arriver au chiffrage RSA, mais attention je ne vais pas développer. Je vais cependant me documenter dessus. Le fait de ne pas développer me permettra de mettre une sorte d'hameçon afin que les examinateurs me posent des questions dessus en entretien.
Ensuite, au sujet de la génération aléatoire des clés, je ne sais pas si je pourrai caser ça dans tout ceci car 10 minutes c'est très très court.
Je n'ai pas encore réellement de problématique mais est-ce que mon "plan" de ci-dessus peut se tenir ?
Merci d'avance.
Et puis tant qu'on y est, pourquoi persistes-tu à écrire VERNAM ? C'est un nom propre, pas un sigle. Écris-tu "le théorème de FERMAT" ou "les suites de CAUCHY" ?
Re bonjour.
"C'est le standard de chiffrement symétrique. On ne peut pas tout faire avec l'AES seul (en fait on ne peut pas faire grand-chose...)"Est-ce que tu pourrai me donner des exemples ? J'imagine mais c'est pour avoir des cas précis. On va utiliser le RSA pour chiffrer des clés AES par exemple, il est symétrique, etc...
Pour le vernam, oui, effectivement, je n'ai pas écrit en majuscule volontairement.
Aussi, par rapport au "2^8192" c'était juste pour donner une idée des nombres de cas à tester.
Il y a autant de clés que de messages et on peut donc obtenir tous les messages possibles en tentant de déchiffrer, ce qui ne nous renseigne absolument pas sur le message original, j'ai compris ça.
Mais j'ai précisé le "2^8192" du nombres de cas à tester pour 1MO, encore plus si le message original n'a pas de sens si je peux dire. C'était juste pour un ordre d'idée, sachant que 1MO c'est très négligeable et 2^8192 qu'on qualifie d'infini déjà...
Alors j'ai réfléchi. Je ne sais pas si l'idée de "plan" que j'ai donné plus haut est convenable. Introduire les principes de générations purement aléatoires de clé serai long. Déjà que rien que pour expliquer convenablement l'algorithme de chiffrement AES, 10 minutes ça passe vite...
Je n'ai de plus pas d'expérience à faire.
J'en ai parlé à mon professeur de mathématiques et il m'a dit que je pourrai implémenter un programme de chiffrement AES en mapple, Caml ou en C++ que je connais même si ça fait au moins un an que je n'ai pas codé.
Mais même, je vais faire le programme, et ensuite... ça aura montré quoi, je ne sais pas ...
("encore plus si le message original n'a pas de sens si je peux dire" sachant qu'en déchiffrant on regarde ce qui a du sens donc si le message original n'a déjà pas de sens...)
Ensuite on m'a dit que je peux faire des simulations, ou autre...
(désolé du double poste mais pas de fonction édit. ici, dommage...)
Et aussi :
1MO = 10^6 octets = 1 000 ko = 1 000 * 1 000 octet = 1 000 000 octets = 8 000 000 bits
Donc 2^(8 000 000) cas.
Désolé de double poster.
Après une recherche sur wikipedia j'en ai appris sur les ko, kio, mo/ mio enfin, bref. Hors sujet mais l'erreur de notation que j'ai fais plus haut n'arrivera plus... c'est honteux... x)
Voila, donc pour revenir au sujet, celui du plan auquel j'ai pensé... + les éventuelles expériences/simulations/implémentations...
Je fais des recherches de mon côté aussi, je veux juste des conseils de gens qui s'y connaissent (ou non tout est relatif)
Et quand tu utiliseras ton programme AES que tu auras écrit toi-même, précise bien que c'est juste pour l'exemple et que tu n'utiliserais jamais ce programme en pratique. Ça montrera aux examinateurs que tu as compris un second principe important : on n'utilise jamais des algorithmes ou des implémentations qu'on a fait soi-même et qui n'ont pas été testés intensivement et par beaucoup de monde. Il y a 100 % de chances que ton programme soit horriblement buggé et comporte de nombreuses failles.
Ok d'accord, je vais regarder pour les différents mode de chiffrement de l'AES, leurs différences, etc...
pour voire ce que je vais en faire
Oui, désolé, merci de me corriger^^
Intéressant^^
Par contre, je vais faire de mon mieux pour comprendre et assimiler tout ça, après coder si possible, ça va être le plus difficile je pense.
Quoi que non, pour le C++ j'ai pensé à la librairie Crypto++ qui aide pas mal et diminue d'au moins 95% la quantité de choses à faire. Je ne sais par contre pas si je pourrai implémenter en Caml ou Maple...
En effet, ça serait un peu lourd de coder à la fois AES, puis le chiffrement "complet", en intégrant le mode d'opération. Donc tu peux utiliser une bibliothèque qui te fera l'AES, puis faire le reste toi-même. Je ne connais ni C++, ni Caml, ni Maple, donc je ne peux pas t'aider pour ça. (J'utilise OpenSSL en C.)
Re bonjour, j'ai réfléchi sur le sujet et traiter les différentes modes d'opérations c'est encore trop lourd malheureusement, même avec les schémas de la page wikipedia que vous m'avez donné... c'est délicat, déjà à comprendre.
Je pense donc rester sur l'AES simple (par bloc donc je crois) et parler des problèmes de clés.
Et si possible introduire le RSA, ou autres méthodes de générations aléatoires de clé comme le bruit ou autre....
Car pour comprendre et implémenter les différents modes de l'AES, j'ai peur de noyer le jury......
Désolé du double poste :
Idem si ça ne dérange pas, j'aimerai que vous me (ré)expliquez la différence entre la puissance de l'AES et entre le XOR.
Car clé de 192/256 bit, elle va se répéter dans le message non? Juste une explication du pourquoi les analyses séquentielles ou autre deviennent inefficaces malgré la "petite" taille de la clé face à celle du message à chiffrer ?
P.S. : "le XOR" n'est pas un algorithme de chiffrement, c'est une opération logique. Pour en faire un algorithme de chiffrement, il faut également considérer l'autre opérande. On peut chiffrer un message en faisant un XOR entre ce message et quelque chose, mais alors tout dépend de la nature de ce quelque chose. Donc, dire "le XOR" ne dit en fait rien du tout.
Re bonjour, mal exprimé encore une fois.
Je voulais dire, si par exemple on veut chiffrer 1 MO de binaire,
on a une clé de taille 10 octet, la clé va se répéter lors du chiffrement, cela sera visible par les différentes méthodes d'analyse, etc.
Idem, si on doit chiffrer 1 MO avec l'AES, avec une clé 128 bit, aura-t-on le même problème qu'avec le XOR (la clé est de taille très très inférieure au message à chiffrer) ?
Bref, qu'est-ce qui défini réellement la puissance de l'AES?
Soit un message de taille n à chiffrer, on utilise le XOR, clé de taille 128 octet = 1024 bits soit 2^1024 cas par force brute à tester, où 128 < n (outre les autres méthodes d'analyse)
Idem, pour l'AES, on aura du 2^1024 non en chiffrant le même message avec une clé 128 bit je crois ?
La force de l'AES vient du fait qu'aucune cryptanalyse puissante n'ai été trouvée pour l'instant, contrairement au XOR?
Vous devez être membre accéder à ce service...
Pas encore inscrit ?
1 compte par personne, multi-compte interdit !
Ou identifiez-vous :