"On ne parle pas d'algorithme mais de protocole [...] qui évite le rejeu" ...
Donc tu implémentes bien un algorithme.
Un protocole c'est pas juste "le troisième bit à gauche à 1", il peut y avoir des algorithmes. Et pour éviter le rejeu, c'est pas avec juste une bonne structure de donnée, mais avec les algorithmes sous-jacents.
Excuse-moi mais ce que tu racontes n'a (dans le contexte de cette discussion du moins) absolument aucun sens.
Selon Wikipédia : "Dans les réseaux informatiques et les télécommunications, un protocole de communication est une spécification de plusieurs règles pour un type de communication particulier." Par opposition à (même source) : "un algorithme est un énoncé dans un langage bien défini d’une suite d’opérations permettant de résoudre par calcul un problème."
Bref, un algorithme permet de résoudre un problème. Un protocole, c'est une convention pour la communication entre plusieurs personnes, qui apporte certaines garanties sur le déroulement des échanges.
Quant à la question du rejeu, il s'agit d'éviter qu'un message intercepté puisse être renvoyé plus tard, comme si c'était un message neuf (pense à un ordre de virement : même si le protocole est parfaitement sécurisé, si ton message est intercepté et renvoyé 10 fois par l'attaquant, bah tu risques d'avoir moins d'argent que prévu sur ton compte).
Désolé si tu estime qu'un programme qui a rien a voir avec les spécifs est un bon programme, surtout si c'est de la crypto, alors tes programmes vont pas êtres très solides.
Il peut s'agir d'un bon programme, simplement on va avoir du mal à le prouver. Je bosser actuellement sur un précompilateur C pour programmes coopératifs qui est une vraie tuerie en matières de performances ; c'est un excellent programme. Mais on n'a pas encore prouvé que son fonctionnement est correct. D'un côté on la qualité, de l'autre la preuve de cette qualité.
Il faut quand même savoir que presque aucun logiciel de crypto n'est prouvé formellement - les algorithmes et protocoles sous-jacents peuvent éventuellement l'être (et encore pas toujours), mais le logiciel en lui-même, c'est quelque chose de très nouveau et exceptionnel. Cela n'a pas empêché d'avoir des logiciels de qualité jusqu'ici (comme ssh par exemple).
"On suit pas la spécifs ... mais je vous assure mon truc c'est trop de la balle".
"On suit pas la norme RSA, mais je vous assure, mon truc est encore plus secure. Comment ? Ah ca pas besoin de vérifier contre la specif (ni de vérifier la specif), vu que c'est moi qui vous le dis. Non ca vous convient pas? bizarre"
Là encore, tu confonds. Norme et spécification sont deux choses très différentes. D'un côté, tu as des standards adoptés et reconnus par la communauté (industrielle, scientifique, etc.). De l'autre, tu as des choix de conception interne. Maintenir l'adéquation entre le programme et la spécification, c'est comme entre le programme et la documentation : c'est un boulot énorme, et rarement mené à bien.
Naturellement, ce serait mieux que les deux aillent ensemble. Et c'était précisément le sens de mon premier message.
Mais merci de ne pas tout déformer. A priori (je n'ai aucune information là-dessus), quand MS dit "on utilise RSA à cet endroit", ils utilisent RSA conformément au standard. Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
Par contre, en ce qui concerne les protocoles (tu noteras la différence), ils ont à faire face à de nouveaux besoins, pour lesquels il n'y a ni norme, ni standard : ils sont donc logiquement amenés à créer de nouveaux protocoles, selon des spécifications internes, et parfois, ça évolue.
[^] # Re: La documentation c'est bien joli, mais...
Posté par MrLapinot (site web personnel) . En réponse au journal Un grand jour pour Samba. Évalué à 2.
Excuse-moi mais ce que tu racontes n'a (dans le contexte de cette discussion du moins) absolument aucun sens.
Selon Wikipédia : "Dans les réseaux informatiques et les télécommunications, un protocole de communication est une spécification de plusieurs règles pour un type de communication particulier." Par opposition à (même source) : "un algorithme est un énoncé dans un langage bien défini d’une suite d’opérations permettant de résoudre par calcul un problème."
Bref, un algorithme permet de résoudre un problème. Un protocole, c'est une convention pour la communication entre plusieurs personnes, qui apporte certaines garanties sur le déroulement des échanges.
Quant à la question du rejeu, il s'agit d'éviter qu'un message intercepté puisse être renvoyé plus tard, comme si c'était un message neuf (pense à un ordre de virement : même si le protocole est parfaitement sécurisé, si ton message est intercepté et renvoyé 10 fois par l'attaquant, bah tu risques d'avoir moins d'argent que prévu sur ton compte).
Il peut s'agir d'un bon programme, simplement on va avoir du mal à le prouver. Je bosser actuellement sur un précompilateur C pour programmes coopératifs qui est une vraie tuerie en matières de performances ; c'est un excellent programme. Mais on n'a pas encore prouvé que son fonctionnement est correct. D'un côté on la qualité, de l'autre la preuve de cette qualité.
Il faut quand même savoir que presque aucun logiciel de crypto n'est prouvé formellement - les algorithmes et protocoles sous-jacents peuvent éventuellement l'être (et encore pas toujours), mais le logiciel en lui-même, c'est quelque chose de très nouveau et exceptionnel. Cela n'a pas empêché d'avoir des logiciels de qualité jusqu'ici (comme ssh par exemple).
Là encore, tu confonds. Norme et spécification sont deux choses très différentes. D'un côté, tu as des standards adoptés et reconnus par la communauté (industrielle, scientifique, etc.). De l'autre, tu as des choix de conception interne. Maintenir l'adéquation entre le programme et la spécification, c'est comme entre le programme et la documentation : c'est un boulot énorme, et rarement mené à bien.
Naturellement, ce serait mieux que les deux aillent ensemble. Et c'était précisément le sens de mon premier message.
Mais merci de ne pas tout déformer. A priori (je n'ai aucune information là-dessus), quand MS dit "on utilise RSA à cet endroit", ils utilisent RSA conformément au standard. Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
Par contre, en ce qui concerne les protocoles (tu noteras la différence), ils ont à faire face à de nouveaux besoins, pour lesquels il n'y a ni norme, ni standard : ils sont donc logiquement amenés à créer de nouveaux protocoles, selon des spécifications internes, et parfois, ça évolue.
J'espère avoir été plus clair cette fois-ci.