On peut s'amuser à tout chiffrer : dès lors impossible de filtrer les données.
Pour cela on peut imaginer utiliser du SSL ; inconvenient : votre FAI peut très bien (sous un gouvernement autoritaire, a cause des dérives des lois anti copie privee, etc...) se mettre à faire du man in the middle, et adieu le cryptage. Et impossible de controler l'identité de celui avec qui on négocie la clef sur un réseau ouvert... Il serait interressant de mettre un oeuvre un tel système de chiffrage avec un plus un degré de furtivité (implementable avant ou apres le chiffrage). Par exemple communiquer les données par requetes sur un fichier .php totalement abstrait et dont le nom importe peu en lui passant ce qui ressemble à un hash md5 en parametre : impossible de filtrer ca sans couper une bonne partie des serveurs web normaux. Pour la réponse utiliser de la stéganographie sur des pages oueb aillant l'air par ailleur totalement plausible mais comportant une part primordial d'aleatoire pour eviter une detection par contenu.
On pourrait aussi stocker une partie des clefs des participants sur le réseau p2p lui même : le handshake deviendrait un échange de données partielles et man in the middle ne serait plus possible. Reste à prévoir un système pour la connexion initiale au réseau.
Enfin il serait souhaitable de maintenir une blacklist des ips pouvant tenter d'attaquer un tel réseau en introduisant des noeuds volontairement defectueux, ou autre.
L'idée telle que je la présente reste un peu basique et il reste possible de filtrer un tel système en faisant l'hypothèse que tout flux est suspect et en essayant de trouver les informations négociée par ce type d'échange, et en aillant des noeuds connecté au réseau pour trouver la partie manquante des clefs. Mais en la poussant un peu plus loin il devrait être possible de construire un système suffisement furtif pour que le cout d'un filtrage augmente au dela de toute consideration économique raisonnable. Par exemple utiliser le blacklistage pour répondre par de fausse clefs au lieu de simplement jeter le participant... Dès lors que le cout du filtrage atteindra un point de non retour, la tentative de filtrage aura échouée.
# Imaginons un handshake un tant soit peu furtif et adieu le filtrage
Posté par Guillaume Knispel . En réponse à la dépêche Pour H4r7.org, le copyleft est victime de la charte anti-piraterie. Évalué à 4.
On peut s'amuser à tout chiffrer : dès lors impossible de filtrer les données.
Pour cela on peut imaginer utiliser du SSL ; inconvenient : votre FAI peut très bien (sous un gouvernement autoritaire, a cause des dérives des lois anti copie privee, etc...) se mettre à faire du man in the middle, et adieu le cryptage. Et impossible de controler l'identité de celui avec qui on négocie la clef sur un réseau ouvert... Il serait interressant de mettre un oeuvre un tel système de chiffrage avec un plus un degré de furtivité (implementable avant ou apres le chiffrage). Par exemple communiquer les données par requetes sur un fichier .php totalement abstrait et dont le nom importe peu en lui passant ce qui ressemble à un hash md5 en parametre : impossible de filtrer ca sans couper une bonne partie des serveurs web normaux. Pour la réponse utiliser de la stéganographie sur des pages oueb aillant l'air par ailleur totalement plausible mais comportant une part primordial d'aleatoire pour eviter une detection par contenu.
On pourrait aussi stocker une partie des clefs des participants sur le réseau p2p lui même : le handshake deviendrait un échange de données partielles et man in the middle ne serait plus possible. Reste à prévoir un système pour la connexion initiale au réseau.
Enfin il serait souhaitable de maintenir une blacklist des ips pouvant tenter d'attaquer un tel réseau en introduisant des noeuds volontairement defectueux, ou autre.
L'idée telle que je la présente reste un peu basique et il reste possible de filtrer un tel système en faisant l'hypothèse que tout flux est suspect et en essayant de trouver les informations négociée par ce type d'échange, et en aillant des noeuds connecté au réseau pour trouver la partie manquante des clefs. Mais en la poussant un peu plus loin il devrait être possible de construire un système suffisement furtif pour que le cout d'un filtrage augmente au dela de toute consideration économique raisonnable. Par exemple utiliser le blacklistage pour répondre par de fausse clefs au lieu de simplement jeter le participant... Dès lors que le cout du filtrage atteindra un point de non retour, la tentative de filtrage aura échouée.