Bonjour à tous,
Chiffrer ses courriels avec de l'asymétrique, c'est bien, mais si le correspondant n'a pas fait cet effort, alors c'est un peu compliqué (vu qu'il n'a pas de clés à nous fournir).
Je me suis donc dit : ne serait-il pas possible de chiffrer en symétrique automatiquement les courriels envoyés (ainsi que leurs pièces jointes) via AES, le tout sans installer quoique ce soit ?
Il existe, par exemple, une bibliothèque implémentant AES en Javascript.
Je cherche donc une solution me permettant de :
1. Chiffrer en AES texte et pièces jointes avant l'envoi du courriel (donc stocké chiffré sur le serveur) ;
2. Déchiffrage du tout chez le correspondant, soit dans le logiciel de messagerie, soit plus simplement dans son navigateur ;
3. Ne pas envoyer le contenu chiffré ou non sur un serveur distant lors du déchiffrement.
Je vois ça comme une solution du pauvre pour la correspondance avec des gens qui n'ont pas de système PGP installé, et qui ne nécessite pas d'installer quoique ce soit à la réception.
Pensez-vous que c'est une approche viable ? Y a-t-il des outils adaptés ?
Me proposez-vous une autre approche ?
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la clé ?
Posté par Jiehong (site web personnel) . Évalué à 2.
La clé est donné via un autre canaux, mais pas par courriel.
[^] # Re: la clé ?
Posté par Jiehong (site web personnel) . Évalué à 4.
Je me corrige moi-même, car c'est bien moche : « la clé est envoyée via un autre canal, mais pas par courriel ».
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: la clé ?
Posté par Jiehong (site web personnel) . Évalué à 3.
Sauf qu'en pratique les destinataires ne recevrons que ceux qui leurs sont envoyés, ce qui change un peu la donne. Mais une fois la clé compromise, c'est plus embêtant.
Après, mon but c'était plutôt de palier un besoin momentané avec une personne spécifique…
# Quelques difficultés...
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Il y a quelques difficultés, la principale et non la moindre étant conceptuelle: c'est difficile confier le chiffrement/déchiffrement à une librarie JS, car cette dernière sera chargée à la volée par ton navigateur sans possibilité de vérifier qu'elle n'a pas été compromise. Sans parler de la possibilité d'attaque depuis un autre code javascript malicieux par exemple, et tout ce qu'on connait en gestion de risque web.
Côté pratique, il faut bien un moyen de faire passer non seulement le contenu chiffré en AES mais également la clé de déchiffrement, ce qui suppose un canal sécure. Si ce dernier existe, le plus simple est d'envoyer le contenu sensible directement à travers lui. S'il pré-existe la connexion sécure, c'est possible de faire un one-time-pad. S'il n'existe pas ni avant ni au moment où la communication sécure doit être établie, c'est généralement là qu'intervient la crypto asymétrique: les clés asymétrique chiffrent la clé AES, et le message envoyé (pour faire simple) est "clé AES chiffré"+"contenu chiffré avec AES".
C'est très simplifié, hein, c'est rapide, je file faire autre chose… :)
[^] # Re: Quelques difficultés...
Posté par Jiehong (site web personnel) . Évalué à 3.
Mon but n'est pas d'envoyer la clé par courriel, sinon, c'est inutile.
Bon, mais je n'y connais pas grand chose en JS, mais si le code exécuté en JS n'est pas sécure, alors c'est un peu la m*****.
[^] # Re: Quelques difficultés...
Posté par maboiteaspam . Évalué à 1.
Je ne sais plus si c'est corrigé depuis mais en effet, le javascript by design est non sécurisé
https://www.youtube.com/watch?v=y6CnUiW0J8g
Ceci dit, cela s'applique particulièrement au JS in browser, car c'est là qu'on mélangera différents providers all together et que la ré écriture JIT pourrait arriver.
JS côté serveur, amha, est moins sensible à ces problèmes car il ne s'expose pas à un cocktail inattendu, toutes les dépendances sont gérées par l'équipe de dév du produit.
Ceci dit, rien n'empêche ne faire un module GO signé pour le chiffrement et faire le reste en JS, par exemple par dessus cozy-light. M'enfin il n'a pas encore atteint la 1.0 ! Sur ces quelques paroles ------>[]
[^] # Re: Quelques difficultés...
Posté par maboiteaspam . Évalué à 2.
Ce serait tellement bien de pouvoir l'échanger en pair à pair directement, facilement et de manière sécurisée…..
# Peut être une solution pour un futur proche
Posté par Anonyme . Évalué à 4. Dernière modification le 30 décembre 2014 à 21:25.
un nouveau protocole de courrier électronique par les créateurs du blackphone et de lavabit: https://darkmail.info
J'avoue que je ne me suis pas tapé les 108 pages de spécifications, et de toutes façons, le contenu me serait certainement passé au dessus de la tête.
Mais pour ceux qui cherchent de nouvelles idées en attendant une éventuelle généralisation de ce protocole, il y a peut être des idées à pioche.
[^] # Re: Peut être une solution pour un futur proche
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
Dans un autre genre, avec un plugin: http://korben.info/chiffrer-entierement-un-site-web-avec-cryptodata.html
# Une autre idée
Posté par dafp . Évalué à 1. Dernière modification le 06 janvier 2015 à 13:35.
Imaginons que je souhaite chiffrer toutes mes correspondances même si en face le destinataire n'a pas de clé.
Je crée une adresse email avec clé gpg qui fera office de destinataire pour tous ceux que je veux contacter qui n'ont pas de clés - comme ça tout les mél de l'adresse email en question sont chiffré sur le serveur.
L'idée serait d'offrir la lecture de l'email (notre réponse) par https (web) pour que n'importe qui puisse le lire. Donc mieux vaut que la page web soit personnel et auto-hébergé (mais on pourrait imaginer un service qui le fasse, mais personnellement je ferai pas confiance). Il faudrait rajouter un plug-in dans le MUA qui gère automatiquement l'email au destinataire avec le lien lui permettant de lire l'email, et sur la page web de l'inviter à créer sa clé gpg, au pire de répondre sur la page web (qui aurait un formulaire), mais de ne pas répondre avec son propre MUA sans chiffrement avec clé publique (et sûrement pas en copiant le texte en quote).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.