北京时间6月4日早间消息，谷歌周二发布了一个新的Chrome浏览器扩展的源代码，可以方便用户对电子邮件进行加密，使得美国国家安全局(以下简称“NSA”)等情报机构的监听难度大幅增加。这款名为End-to-End的加密工具使用OpenPGP开源加密程序编写，可以在用户的电子邮件离开浏览器后对其加密，直到被收件人解密。
该工具还可以方便用户读取发送到其电子邮件服务器中的加密信息。不过，发送和接受邮件的双方都需要使用End-to-End或其他加密工具，才能令该系统真正发挥作用。
此举将对NSA的监听行为构成重大打击。尽管过去20年已经出现过众多加密技术，但PGP和GnuPG等端对端邮件加密技术仍然需要大量人员的介入，而且需要很强的技术能力。NSA也经常利用人为错误来破解加密信息。
“政府不能越权，这一点很重要。”谷歌首席安全官埃里克·格罗斯(Eric Grosse)说，“我们不希望任何政府破坏互联网安全。”
谷歌的新工具可以加大NSA及其他情报机构的工作难度。虽然端对端加密无法彻底消除信息被黑客或情报机构拦截的风险，但却会迫使他们直接入侵用户电脑读取信息，而无法在发送过程中获取。不过，他们也可以通过秘密法院的命令，从电信运营商那里收集信息。
但“棱镜门”曝光者、NSA前雇员爱德华·斯诺登(Edward Snowden)曾在SXSW音乐节上建议技术人员降低端对端加密技术的使用难度。
直到目前，科技公司在推广端对端加密技术时始终比较迟疑，因为这会导致谷歌和雅虎(等公司难以利用用户发送的数据来投放广告。这些科技巨头都没有加入“暗邮联盟”(Dark Mail Alliance)。该组织的发起方是Silent Circle和Lavabit两家重视隐私的通信提供商，他们向微软、谷歌和雅虎提供了新的端对端加密电子邮件协议。
隐私激进人士曾经批评谷歌和其他公司没有尽快支持端对端加密协议。美国民主自由联盟首席技术专家克里斯多夫·索霍伊安(Christopher Soghoian)说：“谷歌想介入你和与你互动的所有人之间，并提供某种形式的附加价值。他们希望成为你与他人之间的纽带，导致这种纽带的安全性难以确保。”
不过，谷歌周二的这一声明表明该公司已经对这些担忧予以重视。
谷歌隐私和安全产品经理史蒂芬·索莫吉(Stephan Somogyi)在博客中写道：“我们意识到这种加密很可能只会用在十分敏感的信息上，或者被那些需要额外保护的人使用。但我们希望End-to-End扩展可以方便人们尽快得到所需的额外安全保护。”
要让End-to-End工具发挥作用，可能还需要再等一段时间。谷歌周二将End-to-End工具的早期开源代码面向密码员、隐私激进人士和工程师发布，希望他们从中寻找错误和后门。谷歌通过名为Vulnerability Reward Program的奖励项目，为找到安全漏洞的工程师提供奖金。
另外，谷歌周二发布的最新数据显示，该公司仍然需要做出很多努力才能确保用户的通信安全。在从谷歌服务器向外发送信息时，该公司会自动加密网络数据流，但如果另外一端的通信服务提供商不支持加密，数据仍然无法得到保护。
谷歌表示，Gmail与其他电子邮件提供商之间的邮件往来有40%至50%没有加密。例如，谷歌与康卡斯特之间的流量只有1%实现加密，而谷歌与雅虎、Facebook、Twitter、Craigslist和亚马逊之间的加密流量占比超过95%。
康卡斯特发言人称，该公司正在测试加密功能，并计划在几周内启用。而该公司的工程师也将在下周出席一次行业会议，并专门探讨此事。
微软也仍有一些工作要做，因为谷歌与微软的Hotmail等服务之间的流量只有半数经过了加密。
https://code.google.com/p/end-to-end/
End-To-End
End-To-End is a Chrome extension that helps you encrypt, decrypt, digital sign, and verify signed messages within the browser using OpenPGP.
This is the source code for the alpha release of the End-To-End Chrome extension. It’s built upon a newly developed, JavaScript-based crypto library. End-To-End implements the OpenPGP standard, IETF RFC 4880, enabling key generation, encryption, decryption, digital signature, and signature verification. We’re releasing this code to enable community review; it is not yet ready for general use.
For more background, please see our blog post.
FAQs：
Since this is source, I could just build this and submit it to the Chrome Web Store?
Please don’t do this.
The End-To-End team takes its responsibility to provide solid crypto very seriously, and we don’t want at-risk groups that may not be technically sophisticated — journalists, human-rights workers, et al — to rely on End-To-End until we feel it’s ready. Prematurely making End-To-End available could have very serious real world ramifications.
One of the reasons we are doing this source code release is precisely so that the community as a whole can help us make sure that we haven’t overlooked anything in our implementation of End-To-End.
Once we feel that End-To-End is ready, we will release it via the Chrome Web Store ourselves.
Using End-To-End
Is my public key exported somewhere when I provide my e-mail address?
No. The public key stays local and isn’t exported unless you explicitly perform that action.
Does End-To-End work on enclosures or only the body of a Gmail message?
Only the body of the message. Please note that, as with all OpenPGP messages, the email subject line and list of recipients remain unencrypted.
I forgot my keyring passphrase!
If you forget your keyring’s passphrase, there is no way to recover your local keys. Please delete the extension, reinstall the extension, and then import the keys from your backup.
How do I set a passphrase on my key?
End-To-End implements passphrases per-keyring, not per-key as other OpenPGP software often does.
Our goal with this choice is to minimize the number of (additional) passphrases you have to remember and enter. The End-To-End keyring passphrase is used to encrypt the keyring when it’s persisted to localStorage. Each time the End-To-End extension loads, it will require the passphrase to be entered once to decrypt the keyring.
If you import a private key that has a passphrase, End-To-End will ask you for that key’s passphrase and decrypt the key. The imported key is then treated just like any other key.
How does End-To-End find a public key when I send a message?
The public key of a recipient needs to be imported into the local keyring before End-To-End can encrypt to it, or verify a signature from it.
What happens if I delete my key and generate a new one?
Your old key will be lost forever. Unless you backed it up, of course.
How can I just sign a message without encrypting it?
To only sign, delete all of the addresses from the recipient’s box in End-To-End’s compose window.
I’d like to import my End-To-End-generated private key into other OpenPGP software.
End-To-End generates Elliptic Curve-based keys, so they’re only supported in GnuPG 2.1 and later, as well as Symantec’s PGP software, but not in GnuPG 1.x or 2.0. We recommend that you either generate a key that you will use with the extension from now on, or generate a non-EC key in other OpenPGP software and import that.
Please note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn’t been released as a stable version yet. To communicate with other people that don’t use End-To-End, you will need to either generate a key in GnuPG and then import it, or build GnuPG 2.1 yourself.
There’re no mentions of public and private keyrings; where are they?
End-To-End uses a single keyring that contains both private and public keys. You can export individual keys from within the Keys and Settings page.
Technical
Why do you only support Elliptic Curve (EC) key generation?
Generating RSA keypairs is very significantly slower than generating EC-based ones. EC-based keys are just as secure. Symantec’s PGP software and GnuPG 2.1 beta both support EC-based keys; we are greatly looking forward to a stable version of GnuPG 2.1 with EC support becoming available.
Please note that you can import existing, non-EC-based keys into End-To-End.
Will End-To-End work on mobile devices?
Not at the moment. End-To-End is implemented as a Chrome extension, and Chrome on mobile devices doesn’t support extensions.
Which RFCs does End-To-End support?
RFC 4880 — OpenPGP Message Format
RFC 6637 — Elliptic Curve Cryptography (ECC) in OpenPGP
End-To-End does not currently support RFC 3156 or RFC 5581.
I’ve found mojibake!
We’ve made efforts to prevent mojibake—for all non-Roman character encodings, not just Japanese—within messages, but you should not be surprised to encounter mojibake in non-message strings, including User IDs.
We perform no automatic character set detection and rely on the presence of the OpenPGP Charset header.
Are the private key(s) kept in memory, are they always purged after every operation, or is there a passphrase cache?
The private keys are kept in memory unencrypted. We recommend making sure your keyring has a passphrase so that private keys are stored encrypted in localStorage.
How safe are private keys in memory?
In memory, the private key is sandboxed by Chrome from other things. When private keys are in localStorage they’re not protected by Chrome’s sandbox, which is why we encrypt them there.
Please note that enabling Chrome’s “Automatically send usage statistics and crash reports to Google” means that, in the event of a crash, parts of memory containing private key material might be sent to Google.
JavaScript Crypto
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.
JavaScript has no native support for many core features used by cryptographic code
Modern JavaScript engines have Typed Arrays; CS-PRNG is available thanks to WebCrypto.
JavaScript cryptographic projects have had serious vulnerabilities in the past, reducing trust in JavaScript as an implementation language
In practice, no common programming language prevents the code from having vulnerabilities.
We hold ourselves to a higher standard; we started from scratch and created a testable, modern, cryptographic library. We created this new core library for End-To-End with support for BigInteger, modular arithmetic, Elliptic Curve, as well as symmetric and public-key encryption. Having done that, we then developed an OpenPGP implementation on top of it.
Parts of End-To-End’s library are already in use within Google. We hope our code will be used widely in future JS cryptographic projects.
JavaScript crypto has very real risk of side-channel attacks
Since JavaScript code doesn’t control the instructions being executed by the CPU — the JavaScript engine can perform optimizations out of the code’s control — it creates the risk of security-sensitive information leaks.
End-To-End requires user interaction for private operations in normal use, mitigating this risk. Non-user-interaction actions are rate-limited and done in fixed time. End-To-End’s crypto operations are performed in a different process from the web apps it interacts with.
The End-To-End library is as timing-aware it can be and we’ve invested effort to mitigate any exploitable risk.
JavaScript code doesn’t control memory; it’s not really possible to reliably delete intermediate values
The threat model we are trying to address discounts adversaries with physical access and users with malware outside the browser. Chrome’s design means that extensions should be safe against other extensions. Adversaries with this level of access have a plethora of attacks available to compromise data even in systems that control their memory carefully and wipe it.
What about XSS and related bugs
End-To-End uses Content Security Policy as well as inherently safe APIs in frameworks (strict Closure Templates). End-To-End doesn’t trust any website’s DOM or context with unencrypted data. We have tried to ensure that the interaction between the extension and websites is minimal and does not reveal secrets to the website.
Bugs
Are End-To-End security bugs eligible for Google’s Vulnerability Rewards Program?
Yes, we have specifically expanded the scope of our Vulnerability Rewards Program to include End-To-End. This means that reports of exploitable security bugs within End-To-End are eligible for a reward.
What about other bugs?
One of the reasons our first launch is source code only is because our past experience tells us that brand new implementations of the OpenPGP standard need time to mature. We have every expectation of encountering interesting bugs, particularly ones related to interop with other OpenPGP software, and existing keys and messages.