End-to-End de Google disponible en open source
L'outil permet de chiffrer directement ses messages dans le navigateur avant de les envoyer

Le , par Amine Horseman, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de GeoTrouvePas GeoTrouvePas - Membre éprouvé https://www.developpez.com
le 17/12/2014 à 18:10
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.
Avatar de benjani13 benjani13 - Membre expérimenté https://www.developpez.com
le 17/12/2014 à 21:18
Citation Envoyé par GeoTrouvePas  Voir le message
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!
Avatar de azias azias - Membre éclairé https://www.developpez.com
le 17/12/2014 à 22:46
Citation Envoyé par GeoTrouvePas  Voir le message
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.
Avatar de nirgal76 nirgal76 - Membre expérimenté https://www.developpez.com
le 18/12/2014 à 11:41
Citation Envoyé par GeoTrouvePas  Voir le message
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 ?
Avatar de bhamp0 bhamp0 - Membre actif https://www.developpez.com
le 18/12/2014 à 21:55
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é.
Avatar de Algo D.DN Algo D.DN - Membre éprouvé https://www.developpez.com
le 19/12/2014 à 10:46
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/ ;[)
Offres d'emploi IT
Ingénieur de développement C# .Net - H-F
Omniciel - Provence Alpes Côte d'Azur - sophia
DEVLOPPEUR MOBILE IOS & ANDROID
LA CREA MULTIMEDIA - Midi Pyrénées - TOULOUSE
Développeur(se) informatique php5 (h/f)
Atos - Rhône Alpes - Lyon (69000)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil