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.
Et en quoi un protocole ne peut pas se baser sur un ou plusieurs algorithmes ?
...
Tiens question conne, les protocoles de routages, ils reposent ou pas sur des algorithmes de routages ?
Les protocoles censé d'assurer l'intégrité d'une communication, ils reposent ou pas sur des algorithmes de détection et de correction d'erreur ?
Les protocoles de chiffrements (ssl par exemple), ils reposent ou pas sur des algorithmes de chiffrements?
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).
Merci de la précision, ce que je savais déjà, mais je ne vois pas en quoi ca infirme ce que je disais. Ca confirme meme plutot vu que tu repose sur un système pour éviter le rejeu. Ce système reposant forcément (en partie) sur un algorithme quelconque (ca peut être une simple signature d'un timestamp, ce qui est déja constituf d'un algorithme).
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.
Je n'ai jamais dis le contraire d'ailleurs. Cf ma remarque sur IBM & co.
Simplement si tu n'arrive déjà pas a avoir une spécif à jour, alors savoir si ton code correspond encore à la norme ou pas, sachant que la norme est censé être à un niveau encore supérieur à la specif, t'es pas sortie de l'auberge.
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.
Je m'en doute bien.
Pour avoir du implémenter le systeme de signature de RSA (projet de fin d'année), c'est un truc très guidé, mais aussi assez compliqué (ah les joies du PSS. A ce propos, la norme pkcs#1 décrit à la fois l'algorithme de chiffrement , et le protocole pour chiffrer les données ;) ). où il y a des conversions entre chaines de caractères qu'il faut lire comme des chaines de caractères, puis comme un nombre entier,
Avec pour ma part des modulos qui se trimballent un peu partout pour vérifier que l'on reste bien sur les même données lors des conversions.
Si tu ne suis pas parfaitement bien la norme (ou la spécif initiale), alors ca peut marcher, mais tu peux avoir un effet de bord que tu ne vois pas dans la norme (qui elle a été vérifiée) et qui peut conduire à une perte de sécurité : Tu obtient un algorithme à la sécurité "propriétaire" : il est différent de la norme, et bien souvent il n'a pas été vérifié.
Les spécifications permettant justement de faire le lien entre ce qui a été (ou voulu être) fait, et la norme que l'on doit suivre.
Si elles ne sont pas a jour, comment peut tu vérifier que ce que tu as bien fait ce que tu as voulu faire ;)
Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
MS a pas besoin , ils sont potes avec la NSA (NSA_KEY ;))
:P
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.
Le manque de spécification nuit tout autant à la prouvabilité et donc à la sécuritée.
Encore une fois je n'ai JAMAIS dis que c'était facile (ni de prouver, ni de créer,ni de maintenir les specs, etc...).
De plus, comme tu le fais remarquer : ils ont en face des besoins nouveaux. Leur réponse est donc nouvelle, et avec une grande chance, pas décortiqué par la communauté internationale des cryptographes.
Enfin, quant tu fais évoluer quelquechose, tu peux rajouter des bugs sans trop de difficulté. Si les specs sont pas à jour, les tests sans doute pas, et le process de Q&A ne doit pas être super efficient (manque de specs, de test, ...).
J'espère avoir été plus clair cette fois-ci.
Oui, et je t'en remercie ;)
[^] # Re: La documentation c'est bien joli, mais...
Posté par briaeros007 . En réponse au journal Un grand jour pour Samba. Évalué à 2.
Et en quoi un protocole ne peut pas se baser sur un ou plusieurs algorithmes ?
...
Tiens question conne, les protocoles de routages, ils reposent ou pas sur des algorithmes de routages ?
Les protocoles censé d'assurer l'intégrité d'une communication, ils reposent ou pas sur des algorithmes de détection et de correction d'erreur ?
Les protocoles de chiffrements (ssl par exemple), ils reposent ou pas sur des algorithmes de chiffrements?
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).
Merci de la précision, ce que je savais déjà, mais je ne vois pas en quoi ca infirme ce que je disais. Ca confirme meme plutot vu que tu repose sur un système pour éviter le rejeu. Ce système reposant forcément (en partie) sur un algorithme quelconque (ca peut être une simple signature d'un timestamp, ce qui est déja constituf d'un algorithme).
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.
Je n'ai jamais dis le contraire d'ailleurs. Cf ma remarque sur IBM & co.
Simplement si tu n'arrive déjà pas a avoir une spécif à jour, alors savoir si ton code correspond encore à la norme ou pas, sachant que la norme est censé être à un niveau encore supérieur à la specif, t'es pas sortie de l'auberge.
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.
Je m'en doute bien.
Pour avoir du implémenter le systeme de signature de RSA (projet de fin d'année), c'est un truc très guidé, mais aussi assez compliqué (ah les joies du PSS. A ce propos, la norme pkcs#1 décrit à la fois l'algorithme de chiffrement , et le protocole pour chiffrer les données ;) ). où il y a des conversions entre chaines de caractères qu'il faut lire comme des chaines de caractères, puis comme un nombre entier,
Avec pour ma part des modulos qui se trimballent un peu partout pour vérifier que l'on reste bien sur les même données lors des conversions.
Si tu ne suis pas parfaitement bien la norme (ou la spécif initiale), alors ca peut marcher, mais tu peux avoir un effet de bord que tu ne vois pas dans la norme (qui elle a été vérifiée) et qui peut conduire à une perte de sécurité : Tu obtient un algorithme à la sécurité "propriétaire" : il est différent de la norme, et bien souvent il n'a pas été vérifié.
Les spécifications permettant justement de faire le lien entre ce qui a été (ou voulu être) fait, et la norme que l'on doit suivre.
Si elles ne sont pas a jour, comment peut tu vérifier que ce que tu as bien fait ce que tu as voulu faire ;)
Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.
MS a pas besoin , ils sont potes avec la NSA (NSA_KEY ;))
:P
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.
Le manque de spécification nuit tout autant à la prouvabilité et donc à la sécuritée.
Encore une fois je n'ai JAMAIS dis que c'était facile (ni de prouver, ni de créer,ni de maintenir les specs, etc...).
De plus, comme tu le fais remarquer : ils ont en face des besoins nouveaux. Leur réponse est donc nouvelle, et avec une grande chance, pas décortiqué par la communauté internationale des cryptographes.
Enfin, quant tu fais évoluer quelquechose, tu peux rajouter des bugs sans trop de difficulté. Si les specs sont pas à jour, les tests sans doute pas, et le process de Q&A ne doit pas être super efficient (manque de specs, de test, ...).
J'espère avoir été plus clair cette fois-ci.
Oui, et je t'en remercie ;)