Discussion :

[VivienD]

Bonjour,


Je suis en train de développer un «petit» projet personnel qui consiste en la programmation d'une bibliothèque pour la communication réseau via le protocole TCP. Toutefois, je bute sur le cas des «messages longs», c'est-à-dire des messages requêtes et des réponses dont la taille peut (aisément) excéder le kibioctet. Je considère qu'il est nécessaire de s'assurer de l'intégrité de l'information alors transmise. Voici comment je compte m'y prendre.

1. Envoi du paquet de début de message long avec l'identifiant du message, la taille des données à transmettre et leur signature.
2. Envoi de chaque paquet avec en en-tête la taille des données transmises (32 kio max.) et leur signature.
3. Envoi du paquet de fin de message long.

Cette procédure utilisera un système d'acquittement et de renvoi pour éviter tout problème dû à la corruption des données lors de leur transmission. Par ailleurs, si les données sont cryptées, alors les signatures envoyées concerneront le chiffre et non pas les données originelles.

Le cœur de mon problème concerne la génération des signatures. Je souhaite utiliser une fonction de hachage, mais je ne sais pas si je peux me contenter d'une fonction «simple», comme le MD5 ou le SHA-0, ou si je dois utiliser une fonction «plus élaborée», comme le SHA-2 ou le SHA-3. Ce dilemme me turlupine et mon manque d'expérience en la matière m'empêche de le résoudre.


Merci d'avance pour votre aide.


Adishatz!


PS: Veuillez m'excuser si j'ai créé ce sujet dans la mauvaise rubrique.

[Ble4Ch]

Je ne veux pas dire de bêtises, mais le protocole TCP assure l'intégrité du message par accusé de réception de la part du destinataire. Que le message fasse 1 octet ou 100... Chaque paquet est vérifié par le destinataire, sinon l'émetteur renvoie le paquet.

Donc pourquoi revérifier l'intégrité du message ? A part alourdir davantage les échanges sur le réseau.

[VivienD]

Je ne veux pas dire de bêtises, mais le protocole TCP assure l'intégrité du message par accusé de réception de la part du destinataire. Que le message fasse 1 octet ou 100... Chaque paquet est vérifié par le destinataire, sinon l'émetteur renvoie le paquet.

Donc pourquoi revérifier l'intégrité du message ? A part alourdir davantage les échanges sur le réseau.

Alors, il y a un truc que je ne comprends pas. Pourquoi certains fichiers téléchargeables présents sur la toile, comme les images de CD/DVD d'installation de Linux, se retrouvent accompagnés de fichier(s) texte(s) contenant une somme de contrôle (généralement MD5), alors que le protocole utilisé lors du téléchargement (généralement FTP, HTTP ou BitTorrent) repose sur le TCP?

[sevyc64]

Parce que rien ne prouve que le fichier que tu télécharge réellement est bien le fichier qui a été mis au téléchargement au départ.
En fournissant la signature du fichier mis au téléchargement au départ tu peux vérifier à l’arrivée que le fichier que tu as téléchargé n'a pas été corrompu par l'ajout de virus pas exemple.

Ensuite tout dépend les protocoles de téléchargements, s'ils sont sur TCP, ok, mais s'ils sur UDP, l'intégrité n'est pas assurée.
Des protocoles comme Bittorrent utilise aussi bien TCP que UDP

[VivienD]

Parce que rien ne prouve que le fichier que tu télécharge réellement est bien le fichier qui a été mis au téléchargement au départ.
En fournissant la signature du fichier mis au téléchargement au départ tu peux vérifier à l’arrivée que le fichier que tu as téléchargé n'a pas été corrompu par l'ajout de virus pas exemple.
[...]

Je n'avais pas vu ça sous cet angle. Pas bête.

[...]
Ensuite tout dépend les protocoles de téléchargements, s'ils sont sur TCP, ok, mais s'ils sur UDP, l'intégrité n'est pas assurée.
Des protocoles comme Bittorrent utilise aussi bien TCP que UDP

Je ne savais pas que le protocole BitTorrent utilisait aussi bien l'UDP que le TCP. Je me coucherai moins bête, cette nuit.

En résumé, la vérification de l'intégrité des données transmises par l'intermédiaire du protocole TCP grâce à une somme de contrôle (MD5, SHA, ou autres) est, de mon cas, superflue.

[VivienD]

[...]
En résumé, la vérification de l'intégrité des données transmises par l'intermédiaire du protocole TCP grâce à une somme de contrôle (MD5, SHA, ou autres) est, de mon cas, superflue.

Vu que personne ne semble s'insurger contre cette affirmation, je la considère comme juste. Ainsi, ce sujet mérite d'être étiqueté comme résolu.

Merci de votre aide.

Adishatz!

[sevyc64]

pour uniquement la transmission, oui, c'est superflux.