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 Senior 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 Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0103
Published: 2014-07-29
WebAccess in Zarafa before 7.1.10 and WebApp before 1.6 stores credentials in cleartext, which allows local Apache users to obtain sensitive information by reading the PHP session files.

CVE-2014-0475
Published: 2014-07-29
Multiple directory traversal vulnerabilities in GNU C Library (aka glibc or libc6) before 2.20 allow context-dependent attackers to bypass ForceCommand restrictions and possibly have other unspecified impact via a .. (dot dot) in a (1) LC_*, (2) LANG, or other locale environment variable.

CVE-2014-2226
Published: 2014-07-29
Ubiquiti UniFi Controller before 3.2.1 logs the administrative password hash in syslog messages, which allows man-in-the-middle attackers to obtains sensitive information via unspecified vectors.

CVE-2014-3541
Published: 2014-07-29
The Repositories component in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to conduct PHP object injection attacks and execute arbitrary code via serialized data associated with an add-on.

CVE-2014-3542
Published: 2014-07-29
mod/lti/service.php in Moodle through 2.3.11, 2.4.x before 2.4.11, 2.5.x before 2.5.7, 2.6.x before 2.6.4, and 2.7.x before 2.7.1 allows remote attackers to read arbitrary files via an XML external entity declaration in conjunction with an entity reference, related to an XML External Entity (XXE) is...

Best of the Web
Dark Reading Radio