URL: https://linuxfr.org/forums/general-cherche-logiciel/posts/idee-de-projet-pour-communications-email Title: Idée de projet pour communications email Authors: dafp Date: 2015年02月18日T10:48:04+01:00 License: CC By-SA Tags: Score: -1 L'idée est de trouver quelque chose en mixant GPG, et ssl pour avoir une communication privé (pas forcément anonyme) avec des individus qui ne savent pas utiliser GPG - ou ne connaissent même pas son existence. Mon idée serait celle-ci (j'essaie de détailler un minumum une idée technique - elle peut être mauvaise au niveau de la réalisation, mais je n'attends que des critiques pour améliorer l'idée, voir semblant de programme - qui sait, sans doute ça existe déjà à quelques trucs près): . Programme MyHTTPSCommunications : le programme contient une interface accessible par https qui fera office pour chaque compte communiquant avec soi : la création de nouveaux messages, la lecture des messages (listage ou non listage? vu que le mdp peut-être changé je dirai non - à moins que le principe de clé GPG soit repris - mais il faudrait que la clé privé soit chez le contact et non dans le serveur) et modification du mot de passe. L'idée pourrait être finalement la création d'un compte email sur sa machine, cela reviendrait-il au même-je ne sais pas trop? : du moins, comment pourrait-il être au courant des nouveaux emails s'il n'utilise jamais cette adresse (une alerte automatique? un envoie d'email vers l'adresse email qu'on veut lorsqu'on reçoit un nouveau message). . Création de compte unix pour chaque contact avec qui on veut communiquer avec notre programme. . Le mieux est de donner un mdp arbitraire en main propre et permettre au contact de pouvoir le modifier ultérieurement. Pour envoyer un email à un de ses contact: - On envoie un email à "mhc+@mondomaine". - On chiffre le message en utilisant la clé publique GPG de mhc. mhc: - mhc déchiffre le message et le chiffre par rapport au mot de passe du compte (/etc/shadow) : ici je ne sais pas comment ça peut travailler. Mais je pense qu'il n'est pas nécessaire d'avoir quoi que ce soit en clair et l'empreinte du mot de passe suffit à chiffrer (non? - si non : le hic, comment faire?). - mhc crée une entrée accessible par l'interface web. - mhc envoie un email au contact avec seulement le lien pour pouvoir lire le message (et autres explications s'il faut). Le contact lit le message reçu: - Le contact doit taper son mot de passe, et c'est le navigateur qui déchiffre le message (l'idée est de rien avoir en clair, même sur le serveur - sauf à la lecture du navigateur bien sûr). Le contact veut répondre: - Un formulaire existe, et l'utilise. - Le hic est que le serveur sait et reçoit ce qui est écrit, il faudrait que le message soit chiffré par rapport à la clé public GPG du destinataire avant que le serveur reçoive. Pour moi ce n'est pas à mhc de chiffrer le message ici. D'un autre côté c'est que mhc sait déjà ce que le destinataire a dit au contact (lors du déchiffrage du message : certes entre les deux l'interception n'est pas possible, mais si le serveur est corrompu ou écouté, on l'évite pas). - mhc s'occupe d'envoyer l'email chiffré au destinataire. La différence entre cette idée et la création d'un compte email pour chaque correspondant: - Le lien reçu par le correspondant permet d'accéder après mot de passe au message directement; - Le correspondant n'a pas de compte a proprement parler, et on peut facilement gagner en espace en imposant la suppression des messages après x jours; - Tout les messages sont chiffrés (tant que nous aussi utilisions systématiquement le chiffrage GPG). - On peut permettre a des anonymes (en tout cas sans compte) de nous contacter. En imaginant que ce genre de pratiques se généralise, quel serait le mieux finalement? Finalement, en y repensant, le mieux serait simplement que les deux utilisent une clé publique GPG. Mais comment initier les autres? Au final, je suis moi même pénaliser et entraîner dans le non chiffrement, car pour le moment, je n'ai pas de contact proche utilisant GPG, et je ne l'utilise pas. Je garde ces idées un peu fourre tout et mal formuler. Même si au final, on retombe sur quelque chose du moindre dégat.

AltStyle によって変換されたページ (->オリジナル) /