Endpoint // Privacy
6/4/2014
04:00 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Google Adds Chrome Encryption Option For Webmail

An end-to-end encryption test module for Chrome is available now.

Google is now offering a plug-in called End-to-End for the Chrome browser -- in alpha test -- that lets users encrypt their web email messages.

The new End-to-End Chrome extension encrypts, decrypts, digitally signs, and verifies signed messages within the browser using OpenPGP. Google has released the source code for the alpha version of the plug-in, which is built on a new JavaScript-based crypto library.

"'End-to-end' encryption means data leaving your browser will be encrypted until the message's intended recipient decrypts it, and that similarly encrypted messages sent to you will remain that way until you decrypt them in your browser," Stephan Somogyi, product manager for security and privacy at Google, said in a blog post late yesterday.

The goal is to make end-to-end encryption a little more user-friendly and accessible, according to Somogyi. The extension is not yet available in the Chrome Web Store. Google wants it to undergo some community testing and vulnerability research before releasing a final version.

The new Chrome extension answers privacy critics who have been calling for the search engine company to make email encryption available.

"Once we feel that the extension is ready for primetime, we'll make it available in the Chrome Web Store, and anyone will be able to use it to send and receive end-to-end encrypted emails through their existing web-based email provider," Somogyi said. "We recognize that this sort of encryption will probably only be used for very sensitive messages or by those who need added protection. But we hope that the End-to-End extension will make it quicker and easier for people to get that extra layer of security should they need it."

Both the sender and the recipient would need to be using OpenPGP, says Alex McGeorge, a senior security researcher for Immunity Inc. "You still have to go through the whole process of exchanging keys," for example. "If Google put up a public PGP server for everyone on Gmail who wants one, that would be useful. Then you wouldn't have to go through the steps to trade keys."

Google didn't provide all the details on exactly how End-to-End Encryption will work. Sebastian Munoz, CEO of Realsec Inc., says there are still some unanswered questions about the Chrome extension, such as where the encryption keys will be stored and how they will be secured. "From the perspective of Google, the keys should be safely stored on certified HSMs. From the end user's point of view, a certified token or smart card should be used to store the private keys of each person."

Just how secure the extension will be also is unclear, McGeorge says. "JavaScript and crypto have typically been incompatible. A lot has to do with getting good randomness. That is super important for PGP."

However, Google engineers have publicly acknowledged that issue in the past, and they have been working on it. As a matter of fact, Google directly addresses the issue in the FAQ on End-to-End:

    Implementing crypto in JavaScript is considered heretical by some. When we started work on End-To-End, there was no JavaScript crypto library that met our needs, so we built our own. During development we took into consideration all the criticisms and risks that we are aware of, and invested effort to mitigate these risks as much as possible.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0485
Published: 2014-09-02
S3QL 1.18.1 and earlier uses the pickle Python module unsafely, which allows remote attackers to execute arbitrary code via a crafted serialized object in (1) common.py or (2) local.py in backends/.

CVE-2014-3861
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to inject arbitrary web script or HTML via a crafted reference element within a nonXMLBody element.

CVE-2014-3862
Published: 2014-09-02
CDA.xsl in HL7 C-CDA 1.1 and earlier allows remote attackers to discover potentially sensitive URLs via a crafted reference element that triggers creation of an IMG element with an arbitrary URL in its SRC attribute, leading to information disclosure in a Referer log.

CVE-2014-5076
Published: 2014-09-02
The La Banque Postale application before 3.2.6 for Android does not prevent the launching of an activity by a component of another application, which allows attackers to obtain sensitive cached banking information via crafted intents, as demonstrated by the drozer framework.

CVE-2014-5136
Published: 2014-09-02
Cross-site scripting (XSS) vulnerability in Innovative Interfaces Sierra Library Services Platform 1.2_3 allows remote attackers to inject arbitrary web script or HTML via unspecified parameters.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.