Discussion :

[Amine Horseman]

Google : End-to-End disponible en Open Source
L’outil permet de chiffrer directement ses messages dans le navigateur avant de les envoyer

Google vient de publier en Open Source le code de End-to-End : une extension qui permet de chiffrer, signer et vérifier la signature numérique de messages directement dans le navigateur en utilisant OpenPGP.

Au début, cette extension était destinée à Google Chrome, mais en la publiant sur GitHub, le géant du web confirme indirectement qu’il veut faire de cet outil un standard qui pourra être utilisé aussi dans les autres navigateurs tels que Firefox, Opera et Internet Explorer.

« C’est une technologie de camouflage super forte qui brouille les messages avant qu'ils ne quittent leur navigateur et les maintient de cette façon jusqu'à ce qu'ils soient décodés par le destinataire », déclarait en juin dernier Stephan Somogyi, expert en sécurité et confidentialité chez Google. Il expliqua que l’outil permet l'utilisation d'une clé privée pour chiffrer les messages de l’utilisateur sur la machine locale, ce qui fait que même le fournisseur du service de messagerie électronique de ce dernier ne peut pas lire le contenu des messages, puisqu’il n’a pas l’accès à la clé privée qui a été utilisée pour le chiffrement.

« Nous reconnaissons que ce type de chiffrement ne sera probablement utilisé que pour les messages très sensibles », continue Stephan Somogyi. «Mais nous espérons que l’extension sera plus rapide et plus facile pour les utilisateurs qui auront besoin d’une couche de sécurité supplémentaire[/I] »

A noter que le code de l’extension publié désormais sur GitHub a fait l’objet de plusieurs améliorations, notamment avec la contribution de Yahoo depuis août dernier. Aussi, le wiki du projet contient maintenant des informations supplémentaires « à la fois pour les développeurs ainsi que les chercheurs en sécurité qui veulent comprendre comment nous pensons le modèle de sécurité de End-to-End ». Toutefois, l’outil est encore en version alpha. Par conséquent, il n’est pas encore disponible sur le Chrome Web Store.

Visiter la page GitHub du projet

Source : Google Online Security Blog

Et vous ?

Qu’en pensez-vous de cette initiative de Google ?

[GeoTrouvePas]

Cet article remet en question le peu de connaissances que je pensais avoir en la matière alors je vais en profiter pour poser une grosse question de noob :
Si l'expéditeur chiffre son message avec sa propre clé privée, comment fait le destinataire pour le déchiffrer ?
Je croyais que la pratique consistait à chiffrer le message avec la clé publique du destinataire et qu'il ne pouvait être déchiffre qu'avec sa clé privée.

[benjani13]

Cet article remet en question le peu de connaissances que je pensais avoir en la matière alors je vais en profiter pour poser une grosse question de noob :
Si l'expéditeur chiffre son message avec sa propre clé privée, comment fait le destinataire pour le déchiffrer ?
Je croyais que la pratique consistait à chiffrer le message avec la clé publique du destinataire et qu'il ne pouvait être déchiffre qu'avec sa clé privée.

De ce que je comprend de la description du Github l'extension permet une généralisation de PGP au sein du navigateur. Je ne connais pas non plus asse PGP pour expliquer son fonctionnement, je vais aller me documenter!

[azias]

Cet article remet en question le peu de connaissances que je pensais avoir en la matière alors je vais en profiter pour poser une grosse question de noob :
Si l'expéditeur chiffre son message avec sa propre clé privée, comment fait le destinataire pour le déchiffrer ?
Je croyais que la pratique consistait à chiffrer le message avec la clé publique du destinataire et qu'il ne pouvait être déchiffre qu'avec sa clé privée.

Je pense aussi qu'il s’agit d'un coquille dans l'article. D'ailleurs je n'ai pas retrouvé une telle explication par Stephan Somogyi, en revanche j'ai trouvé un commentaire (sur un post de Stephan Somogyi) d'un inconnu qui ressemble fort à ce qui est repris dans l'article. Ce commentaire parle bien bien de la clef publique fournie par le destinataire, pas d'une clef privée.

Au passage, chiffrer un message en utilisant sa propre clef privée a un intérêt mais pas pour rendre le message illisible: c'est un moyen de signer le message. Pour le déchiffrer (le message entier ou juste une partie de signature) le destinataire doit utiliser la clef publique réputée être celle de l’émetteur, si ça fonctionne c'est que ça a bien été signé par le bon émetteur. C'est le principe utilisé pour les signatures par certificat numérique présent dans un certain nombres de logiciels ou pour de l’authentification web. Ça permet aussi de s'assurer qu'un message transmis en clair n'a pas été modifié: en ajoutant une petite signature qui sera par exemple un hash du message chiffré avec la clef privée.

D'une manière générale on peut faire les deux: on chiffre le message à la fois avec la clef publique du destinataire et la clef privée de l’émetteur (dans un ordre ou un autre). Le contenu du message est ainsi à la fois signé et protégé des yeux indiscrets. Mais ça complexifie le processus de vérification des certificats et ralentit le traitement.

[nirgal76]

Cet article remet en question le peu de connaissances que je pensais avoir en la matière alors je vais en profiter pour poser une grosse question de noob :
Si l'expéditeur chiffre son message avec sa propre clé privée, comment fait le destinataire pour le déchiffrer ?
Je croyais que la pratique consistait à chiffrer le message avec la clé publique du destinataire et qu'il ne pouvait être déchiffre qu'avec sa clé privée.

De ce que je pense avoir compris (et implémenté à mon taf !),
l'expéditeur crypte avec sa clé privée et la clé publique du destinataire, lui décrypte avec la clé publique de l'expéditeur et sa clé privée.
le point délicat étant la transmission des clés publiques, car un tiers peut tenter de se faire passer pour ton destinataire, d'ou les certificats pour "assurer" cette transmission.
J'ai bon ?

[bhamp0]

Pour compléter le très bon message de olreak :

L'utilisation du chiffrement asymétrique (1 clef publique et 1 privée) peut permettre d'assurer deux choses :
- la confidentialité de la donnée envoyée : l'envoyeur encode le message avec la clef publique du destinataire, qui sera donc le seul à pouvoir le lire ; aucune garantie, par contre, que le message provienne bien de l'envoyeur (un intermédiaire peut remplacer le message par un autre)
- la provenance de la donnée : l'envoyeur encode le message avec sa clef privée ; par contre, un intermédiaire pourra lire le message

Pour assurer les deux, il faut donc que l'envoyeur encode son message avec sa clef privée, puis l'encodage obtenue avec la clef publique du destinataire. Seul le destinataire peut lire le message et être sûr de son authenticité.

[Algo D.DN]

L'échange de données de manière sécurisé de bout en bout repose avant tout (et surtout) sur la confiance qu'on accorde aux clés entre émetteur/récepteur, il y a un excellent guide qui traduit tout ça de manière accessible ici : https://emailselfdefense.fsf.org/fr/ ;[)