{"id":4145,"date":"2014-06-04T11:03:44","date_gmt":"2014-06-04T03:03:44","guid":{"rendered":"https:\/\/www.icocean.com\/blog\/?p=4145"},"modified":"2014-06-05T13:08:16","modified_gmt":"2014-06-05T05:08:16","slug":"%e8%b0%b7%e6%ad%8c%e6%8e%a8%e5%87%ba%e7%ab%af%e5%af%b9%e7%ab%af%e9%82%ae%e4%bb%b6%e5%8a%a0%e5%af%86%e5%b7%a5%e5%85%b7%ef%bc%9a%e5%af%b9%e6%8a%97nsa%e7%9b%91%e6%8e%a7","status":"publish","type":"post","link":"https:\/\/www.icocean.com\/blog\/?p=4145","title":{"rendered":"\u8c37\u6b4c\u63a8\u51fa\u7aef\u5bf9\u7aef\u90ae\u4ef6\u52a0\u5bc6\u5de5\u5177\uff1a\u5bf9\u6297NSA\u76d1\u63a7"},"content":{"rendered":"<p>\u5317\u4eac\u65f6\u95f46\u67084\u65e5\u65e9\u95f4\u6d88\u606f\uff0c\u8c37\u6b4c\u5468\u4e8c\u53d1\u5e03\u4e86\u4e00\u4e2a\u65b0\u7684Chrome\u6d4f\u89c8\u5668\u6269\u5c55\u7684\u6e90\u4ee3\u7801\uff0c\u53ef\u4ee5\u65b9\u4fbf\u7528\u6237\u5bf9\u7535\u5b50\u90ae\u4ef6\u8fdb\u884c\u52a0\u5bc6\uff0c\u4f7f\u5f97\u7f8e\u56fd\u56fd\u5bb6\u5b89\u5168\u5c40(\u4ee5\u4e0b\u7b80\u79f0\u201cNSA\u201d)\u7b49\u60c5\u62a5\u673a\u6784\u7684\u76d1\u542c\u96be\u5ea6\u5927\u5e45\u589e\u52a0\u3002\u8fd9\u6b3e\u540d\u4e3aEnd-to-End\u7684\u52a0\u5bc6\u5de5\u5177\u4f7f\u7528OpenPGP\u5f00\u6e90\u52a0\u5bc6\u7a0b\u5e8f\u7f16\u5199\uff0c\u53ef\u4ee5\u5728\u7528\u6237\u7684\u7535\u5b50\u90ae\u4ef6\u79bb\u5f00\u6d4f\u89c8\u5668\u540e\u5bf9\u5176\u52a0\u5bc6\uff0c\u76f4\u5230\u88ab\u6536\u4ef6\u4eba\u89e3\u5bc6\u3002<\/p>\n<p>\u8be5\u5de5\u5177\u8fd8\u53ef\u4ee5\u65b9\u4fbf\u7528\u6237\u8bfb\u53d6\u53d1\u9001\u5230\u5176\u7535\u5b50\u90ae\u4ef6\u670d\u52a1\u5668\u4e2d\u7684\u52a0\u5bc6\u4fe1\u606f\u3002\u4e0d\u8fc7\uff0c\u53d1\u9001\u548c\u63a5\u53d7\u90ae\u4ef6\u7684\u53cc\u65b9\u90fd\u9700\u8981\u4f7f\u7528End-to-End\u6216\u5176\u4ed6\u52a0\u5bc6\u5de5\u5177\uff0c\u624d\u80fd\u4ee4\u8be5\u7cfb\u7edf\u771f\u6b63\u53d1\u6325\u4f5c\u7528\u3002<\/p>\n<p>\u6b64\u4e3e\u5c06\u5bf9NSA\u7684\u76d1\u542c\u884c\u4e3a\u6784\u6210\u91cd\u5927\u6253\u51fb\u3002\u5c3d\u7ba1\u8fc7\u53bb20\u5e74\u5df2\u7ecf\u51fa\u73b0\u8fc7\u4f17\u591a\u52a0\u5bc6\u6280\u672f\uff0c\u4f46PGP\u548cGnuPG\u7b49\u7aef\u5bf9\u7aef\u90ae\u4ef6\u52a0\u5bc6\u6280\u672f\u4ecd\u7136\u9700\u8981\u5927\u91cf\u4eba\u5458\u7684\u4ecb\u5165\uff0c\u800c\u4e14\u9700\u8981\u5f88\u5f3a\u7684\u6280\u672f\u80fd\u529b\u3002NSA\u4e5f\u7ecf\u5e38\u5229\u7528\u4eba\u4e3a\u9519\u8bef\u6765\u7834\u89e3\u52a0\u5bc6\u4fe1\u606f\u3002<\/p>\n<p>\u201c\u653f\u5e9c\u4e0d\u80fd\u8d8a\u6743\uff0c\u8fd9\u4e00\u70b9\u5f88\u91cd\u8981\u3002\u201d\u8c37\u6b4c\u9996\u5e2d\u5b89\u5168\u5b98\u57c3\u91cc\u514b\u00b7\u683c\u7f57\u65af(Eric Grosse)\u8bf4\uff0c\u201c\u6211\u4eec\u4e0d\u5e0c\u671b\u4efb\u4f55\u653f\u5e9c\u7834\u574f\u4e92\u8054\u7f51\u5b89\u5168\u3002\u201d<\/p>\n<p>\u8c37\u6b4c\u7684\u65b0\u5de5\u5177\u53ef\u4ee5\u52a0\u5927NSA\u53ca\u5176\u4ed6\u60c5\u62a5\u673a\u6784\u7684\u5de5\u4f5c\u96be\u5ea6\u3002\u867d\u7136\u7aef\u5bf9\u7aef\u52a0\u5bc6\u65e0\u6cd5\u5f7b\u5e95\u6d88\u9664\u4fe1\u606f\u88ab\u9ed1\u5ba2\u6216\u60c5\u62a5\u673a\u6784\u62e6\u622a\u7684\u98ce\u9669\uff0c\u4f46\u5374\u4f1a\u8feb\u4f7f\u4ed6\u4eec\u76f4\u63a5\u5165\u4fb5\u7528\u6237\u7535\u8111\u8bfb\u53d6\u4fe1\u606f\uff0c\u800c\u65e0\u6cd5\u5728\u53d1\u9001\u8fc7\u7a0b\u4e2d\u83b7\u53d6\u3002<!--more-->\u4e0d\u8fc7\uff0c\u4ed6\u4eec\u4e5f\u53ef\u4ee5\u901a\u8fc7\u79d8\u5bc6\u6cd5\u9662\u7684\u547d\u4ee4\uff0c\u4ece\u7535\u4fe1\u8fd0\u8425\u5546\u90a3\u91cc\u6536\u96c6\u4fe1\u606f\u3002<\/p>\n<p>\u4f46\u201c\u68f1\u955c\u95e8\u201d\u66dd\u5149\u8005\u3001NSA\u524d\u96c7\u5458\u7231\u5fb7\u534e\u00b7\u65af\u8bfa\u767b(Edward Snowden)\u66fe\u5728SXSW\u97f3\u4e50\u8282\u4e0a\u5efa\u8bae\u6280\u672f\u4eba\u5458\u964d\u4f4e\u7aef\u5bf9\u7aef\u52a0\u5bc6\u6280\u672f\u7684\u4f7f\u7528\u96be\u5ea6\u3002<\/p>\n<p>\u76f4\u5230\u76ee\u524d\uff0c\u79d1\u6280\u516c\u53f8\u5728\u63a8\u5e7f\u7aef\u5bf9\u7aef\u52a0\u5bc6\u6280\u672f\u65f6\u59cb\u7ec8\u6bd4\u8f83\u8fdf\u7591\uff0c\u56e0\u4e3a\u8fd9\u4f1a\u5bfc\u81f4\u8c37\u6b4c\u548c\u96c5\u864e(\u7b49\u516c\u53f8\u96be\u4ee5\u5229\u7528\u7528\u6237\u53d1\u9001\u7684\u6570\u636e\u6765\u6295\u653e\u5e7f\u544a\u3002\u8fd9\u4e9b\u79d1\u6280\u5de8\u5934\u90fd\u6ca1\u6709\u52a0\u5165\u201c\u6697\u90ae\u8054\u76df\u201d(Dark Mail Alliance)\u3002\u8be5\u7ec4\u7ec7\u7684\u53d1\u8d77\u65b9\u662fSilent Circle\u548cLavabit\u4e24\u5bb6\u91cd\u89c6\u9690\u79c1\u7684\u901a\u4fe1\u63d0\u4f9b\u5546\uff0c\u4ed6\u4eec\u5411\u5fae\u8f6f\u3001\u8c37\u6b4c\u548c\u96c5\u864e\u63d0\u4f9b\u4e86\u65b0\u7684\u7aef\u5bf9\u7aef\u52a0\u5bc6\u7535\u5b50\u90ae\u4ef6\u534f\u8bae\u3002<\/p>\n<p>\u9690\u79c1\u6fc0\u8fdb\u4eba\u58eb\u66fe\u7ecf\u6279\u8bc4\u8c37\u6b4c\u548c\u5176\u4ed6\u516c\u53f8\u6ca1\u6709\u5c3d\u5feb\u652f\u6301\u7aef\u5bf9\u7aef\u52a0\u5bc6\u534f\u8bae\u3002\u7f8e\u56fd\u6c11\u4e3b\u81ea\u7531\u8054\u76df\u9996\u5e2d\u6280\u672f\u4e13\u5bb6\u514b\u91cc\u65af\u591a\u592b\u00b7\u7d22\u970d\u4f0a\u5b89(Christopher Soghoian)\u8bf4\uff1a\u201c\u8c37\u6b4c\u60f3\u4ecb\u5165\u4f60\u548c\u4e0e\u4f60\u4e92\u52a8\u7684\u6240\u6709\u4eba\u4e4b\u95f4\uff0c\u5e76\u63d0\u4f9b\u67d0\u79cd\u5f62\u5f0f\u7684\u9644\u52a0\u4ef7\u503c\u3002\u4ed6\u4eec\u5e0c\u671b\u6210\u4e3a\u4f60\u4e0e\u4ed6\u4eba\u4e4b\u95f4\u7684\u7ebd\u5e26\uff0c\u5bfc\u81f4\u8fd9\u79cd\u7ebd\u5e26\u7684\u5b89\u5168\u6027\u96be\u4ee5\u786e\u4fdd\u3002\u201d<\/p>\n<p>\u4e0d\u8fc7\uff0c\u8c37\u6b4c\u5468\u4e8c\u7684\u8fd9\u4e00\u58f0\u660e\u8868\u660e\u8be5\u516c\u53f8\u5df2\u7ecf\u5bf9\u8fd9\u4e9b\u62c5\u5fe7\u4e88\u4ee5\u91cd\u89c6\u3002<\/p>\n<p>\u8c37\u6b4c\u9690\u79c1\u548c\u5b89\u5168\u4ea7\u54c1\u7ecf\u7406\u53f2\u8482\u82ac\u00b7\u7d22\u83ab\u5409(Stephan Somogyi)\u5728\u535a\u5ba2\u4e2d\u5199\u9053\uff1a\u201c\u6211\u4eec\u610f\u8bc6\u5230\u8fd9\u79cd\u52a0\u5bc6\u5f88\u53ef\u80fd\u53ea\u4f1a\u7528\u5728\u5341\u5206\u654f\u611f\u7684\u4fe1\u606f\u4e0a\uff0c\u6216\u8005\u88ab\u90a3\u4e9b\u9700\u8981\u989d\u5916\u4fdd\u62a4\u7684\u4eba\u4f7f\u7528\u3002\u4f46\u6211\u4eec\u5e0c\u671bEnd-to-End\u6269\u5c55\u53ef\u4ee5\u65b9\u4fbf\u4eba\u4eec\u5c3d\u5feb\u5f97\u5230\u6240\u9700\u7684\u989d\u5916\u5b89\u5168\u4fdd\u62a4\u3002\u201d<\/p>\n<p>\u8981\u8ba9End-to-End\u5de5\u5177\u53d1\u6325\u4f5c\u7528\uff0c\u53ef\u80fd\u8fd8\u9700\u8981\u518d\u7b49\u4e00\u6bb5\u65f6\u95f4\u3002\u8c37\u6b4c\u5468\u4e8c\u5c06End-to-End\u5de5\u5177\u7684\u65e9\u671f\u5f00\u6e90\u4ee3\u7801\u9762\u5411\u5bc6\u7801\u5458\u3001\u9690\u79c1\u6fc0\u8fdb\u4eba\u58eb\u548c\u5de5\u7a0b\u5e08\u53d1\u5e03\uff0c\u5e0c\u671b\u4ed6\u4eec\u4ece\u4e2d\u5bfb\u627e\u9519\u8bef\u548c\u540e\u95e8\u3002\u8c37\u6b4c\u901a\u8fc7\u540d\u4e3aVulnerability Reward Program\u7684\u5956\u52b1\u9879\u76ee\uff0c\u4e3a\u627e\u5230\u5b89\u5168\u6f0f\u6d1e\u7684\u5de5\u7a0b\u5e08\u63d0\u4f9b\u5956\u91d1\u3002<\/p>\n<p>\u53e6\u5916\uff0c\u8c37\u6b4c\u5468\u4e8c\u53d1\u5e03\u7684\u6700\u65b0\u6570\u636e\u663e\u793a\uff0c\u8be5\u516c\u53f8\u4ecd\u7136\u9700\u8981\u505a\u51fa\u5f88\u591a\u52aa\u529b\u624d\u80fd\u786e\u4fdd\u7528\u6237\u7684\u901a\u4fe1\u5b89\u5168\u3002\u5728\u4ece\u8c37\u6b4c\u670d\u52a1\u5668\u5411\u5916\u53d1\u9001\u4fe1\u606f\u65f6\uff0c\u8be5\u516c\u53f8\u4f1a\u81ea\u52a8\u52a0\u5bc6\u7f51\u7edc\u6570\u636e\u6d41\uff0c\u4f46\u5982\u679c\u53e6\u5916\u4e00\u7aef\u7684\u901a\u4fe1\u670d\u52a1\u63d0\u4f9b\u5546\u4e0d\u652f\u6301\u52a0\u5bc6\uff0c\u6570\u636e\u4ecd\u7136\u65e0\u6cd5\u5f97\u5230\u4fdd\u62a4\u3002<\/p>\n<p>\u8c37\u6b4c\u8868\u793a\uff0cGmail\u4e0e\u5176\u4ed6\u7535\u5b50\u90ae\u4ef6\u63d0\u4f9b\u5546\u4e4b\u95f4\u7684\u90ae\u4ef6\u5f80\u6765\u670940%\u81f350%\u6ca1\u6709\u52a0\u5bc6\u3002\u4f8b\u5982\uff0c\u8c37\u6b4c\u4e0e\u5eb7\u5361\u65af\u7279\u4e4b\u95f4\u7684\u6d41\u91cf\u53ea\u67091%\u5b9e\u73b0\u52a0\u5bc6\uff0c\u800c\u8c37\u6b4c\u4e0e\u96c5\u864e\u3001Facebook\u3001Twitter\u3001Craigslist\u548c\u4e9a\u9a6c\u900a\u4e4b\u95f4\u7684\u52a0\u5bc6\u6d41\u91cf\u5360\u6bd4\u8d85\u8fc795%\u3002<\/p>\n<p>\u5eb7\u5361\u65af\u7279\u53d1\u8a00\u4eba\u79f0\uff0c\u8be5\u516c\u53f8\u6b63\u5728\u6d4b\u8bd5\u52a0\u5bc6\u529f\u80fd\uff0c\u5e76\u8ba1\u5212\u5728\u51e0\u5468\u5185\u542f\u7528\u3002\u800c\u8be5\u516c\u53f8\u7684\u5de5\u7a0b\u5e08\u4e5f\u5c06\u5728\u4e0b\u5468\u51fa\u5e2d\u4e00\u6b21\u884c\u4e1a\u4f1a\u8bae\uff0c\u5e76\u4e13\u95e8\u63a2\u8ba8\u6b64\u4e8b\u3002<\/p>\n<p>\u5fae\u8f6f\u4e5f\u4ecd\u6709\u4e00\u4e9b\u5de5\u4f5c\u8981\u505a\uff0c\u56e0\u4e3a\u8c37\u6b4c\u4e0e\u5fae\u8f6f\u7684Hotmail\u7b49\u670d\u52a1\u4e4b\u95f4\u7684\u6d41\u91cf\u53ea\u6709\u534a\u6570\u7ecf\u8fc7\u4e86\u52a0\u5bc6\u3002<br \/>\n<!--nextpage--><br \/>\n<a href=\"https:\/\/code.google.com\/p\/end-to-end\/\" target=\"_blank\">https:\/\/code.google.com\/p\/end-to-end\/<\/a><\/p>\n<p>End-To-End<\/p>\n<p>End-To-End is a Chrome extension that helps you encrypt, decrypt, digital sign, and verify signed messages within the browser using OpenPGP.<\/p>\n<p>This is the source code for the alpha release of the End-To-End Chrome extension. It&#8217;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\u2019re releasing this code to enable community review; it is not yet ready for general use.<\/p>\n<p>For more background,\u00a0<a href=\"http:\/\/googleonlinesecurity.blogspot.com\/2014\/06\/making-end-to-end-encryption-easier-to.html\" rel=\"nofollow\">please see our blog post<\/a>.<\/p>\n<hr style=\"color: #000000;\" \/>\n<p><span style=\"color: #ff0000;\"><strong>FAQs\uff1a<\/strong><\/span><\/p>\n<p><strong>Since this is source, I could just build this and submit it to the Chrome Web Store?<\/strong><\/p>\n<p>Please don\u2019t do this.<br \/>\nThe End-To-End team takes its responsibility to provide solid crypto very seriously, and we don\u2019t want at-risk groups that may not be technically sophisticated \u2014 journalists, human-rights workers, et al \u2014 to rely on End-To-End until we feel it\u2019s ready. Prematurely making End-To-End available could have very serious real world ramifications.<\/p>\n<p>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\u2019t overlooked anything in our implementation of End-To-End.<\/p>\n<p>Once we feel that End-To-End is ready, we will release it via the Chrome Web Store ourselves.<\/p>\n<p><span style=\"color: #0000ff;\"><strong>Using End-To-End<\/strong><\/span><\/p>\n<p><strong>Is my public key exported somewhere when I provide my e-mail address?<\/strong><br \/>\nNo. The public key stays local and isn\u2019t exported unless you explicitly perform that action.<\/p>\n<p><strong>Does End-To-End work on enclosures or only the body of a Gmail message?<\/strong><\/p>\n<p>Only the body of the message. Please note that, as with all OpenPGP messages, the email subject line and list of recipients remain unencrypted.<\/p>\n<p><strong>I forgot my keyring passphrase!<\/strong><br \/>\nIf you forget your keyring\u2019s 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.<\/p>\n<p><strong>How do I set a passphrase on my key?<\/strong><br \/>\nEnd-To-End implements passphrases per-keyring, not per-key as other OpenPGP software often does.<br \/>\nOur 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&#8217;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.<br \/>\nIf you import a private key that has a passphrase, End-To-End will ask you for that key&#8217;s passphrase and decrypt the key. The imported key is then treated just like any other key.<\/p>\n<p><strong>How does End-To-End find a public key when I send a message?<\/strong><br \/>\nThe 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.<\/p>\n<p><strong>What happens if I delete my key and generate a new one?<\/strong><br \/>\nYour old key will be lost forever. Unless you backed it up, of course.<\/p>\n<p><strong>How can I just sign a message without encrypting it?<\/strong><br \/>\nTo only sign, delete all of the addresses from the recipient\u2019s box in End-To-End\u2019s compose window.<\/p>\n<p><strong>I\u2019d like to import my End-To-End-generated private key into other OpenPGP software.<\/strong><br \/>\nEnd-To-End generates Elliptic Curve-based keys, so they&#8217;re only supported in GnuPG 2.1 and later, as well as Symantec\u2019s 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.<br \/>\nPlease note that EC support was added to GnuPG 2.1 beta in 2010, but it hasn\u2019t been released as a stable version yet. To communicate with other people that don&#8217;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.<\/p>\n<p><strong>There&#8217;re no mentions of public and private keyrings; where are they?<\/strong><br \/>\nEnd-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.<\/p>\n<p>Technical<\/p>\n<p><strong>Why do you only support Elliptic Curve (EC) key generation?<\/strong><br \/>\nGenerating RSA keypairs is very significantly slower than generating EC-based ones. EC-based keys are just as secure. Symantec\u2019s 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.<br \/>\nPlease note that you can import existing, non-EC-based keys into End-To-End.<\/p>\n<p><strong>Will End-To-End work on mobile devices?<\/strong><br \/>\nNot at the moment. End-To-End is implemented as a Chrome extension, and Chrome on mobile devices doesn\u2019t support extensions.<\/p>\n<p><strong>Which RFCs does End-To-End support?<\/strong><br \/>\n<a href=\"http:\/\/tools.ietf.org\/html\/rfc4880\" rel=\"nofollow\">RFC 4880<\/a>\u00a0\u2014 OpenPGP Message Format<br \/>\n<a href=\"http:\/\/tools.ietf.org\/html\/rfc6637\" rel=\"nofollow\">RFC 6637<\/a>\u00a0\u2014 Elliptic Curve Cryptography (ECC) in OpenPGP<br \/>\nEnd-To-End does not currently support\u00a0<a href=\"http:\/\/tools.ietf.org\/html\/rfc3156\" rel=\"nofollow\">RFC 3156<\/a>\u00a0or\u00a0<a href=\"http:\/\/tools.ietf.org\/html\/rfc5581\" rel=\"nofollow\">RFC 5581<\/a>.<\/p>\n<p><strong>I\u2019ve found mojibake!<\/strong><br \/>\nWe&#8217;ve made efforts to prevent\u00a0<a href=\"http:\/\/en.wikipedia.org\/wiki\/Mojibake\" rel=\"nofollow\">mojibake<\/a>\u2014for all non-Roman character encodings, not just Japanese\u2014within messages, but you should not be surprised to encounter mojibake in non-message strings, including User IDs.<br \/>\nWe perform no automatic character set detection and rely on the presence of the OpenPGP Charset header.<\/p>\n<p><strong>Are the private key(s) kept in memory, are they always purged after every operation, or is there a passphrase cache?<\/strong><br \/>\nThe 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.<\/p>\n<p><strong>How safe are private keys in memory?<\/strong><br \/>\nIn memory, the private key is sandboxed by Chrome from other things. When private keys are in localStorage they\u2019re not protected by Chrome\u2019s sandbox, which is why we encrypt them there.<br \/>\nPlease note that enabling Chrome\u2019s &#8220;Automatically send usage statistics and crash reports to Google&#8221; means that, in the event of a crash, parts of memory containing private key material might be sent to Google.<\/p>\n<p><span style=\"color: #0000ff;\"><strong>JavaScript Crypto<\/strong><\/span><br \/>\nImplementing 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.<\/p>\n<p><strong>JavaScript has no native support for many core features used by cryptographic code<\/strong><br \/>\nModern JavaScript engines have Typed Arrays; CS-PRNG is available thanks to WebCrypto.<\/p>\n<p><strong>JavaScript cryptographic projects have had serious vulnerabilities in the past, reducing trust in JavaScript as an implementation language<\/strong><br \/>\nIn practice, no common programming language prevents the code from having vulnerabilities.<br \/>\nWe 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.<br \/>\nParts of End-To-End\u2019s library are already in use within Google. We hope our code will be used widely in future JS cryptographic projects.<\/p>\n<p><strong>JavaScript crypto has very real risk of side-channel attacks<\/strong><br \/>\nSince JavaScript code doesn&#8217;t control the instructions being executed by the CPU \u2014 the JavaScript engine can perform optimizations out of the code\u2019s control \u2014 it creates the risk of security-sensitive information leaks.<br \/>\nEnd-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\u2019s crypto operations are performed in a different process from the web apps it interacts with.<br \/>\nThe End-To-End library is as timing-aware it can be and we\u2019ve invested effort to mitigate any exploitable risk.<\/p>\n<p><strong>JavaScript code doesn&#8217;t control memory; it&#8217;s not really possible to reliably delete intermediate values<\/strong><br \/>\nThe threat model we are trying to address discounts adversaries with physical access and users with malware outside the browser. Chrome\u2019s 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.<\/p>\n<p><strong>What about XSS and related bugs<\/strong><br \/>\nEnd-To-End uses Content Security Policy as well as inherently safe APIs in frameworks (strict Closure Templates). End-To-End doesn\u2019t trust any website&#8217;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.<\/p>\n<p><span style=\"color: #0000ff;\"><strong>Bugs<\/strong><\/span><\/p>\n<p><strong>Are End-To-End security bugs eligible for Google\u2019s Vulnerability Rewards Program?<\/strong><br \/>\nYes, 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.<\/p>\n<p><strong>What about other bugs?<\/strong><br \/>\nOne 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.<\/p>\n<nav class=\"page-links\"><strong>\u9875\u9762\uff1a<\/strong> <a href=\"https:\/\/www.icocean.com\/blog\/?p=4145\" class=\"post-page-numbers\"><span class=\"page-num\">1<\/span><\/a> <a href=\"https:\/\/www.icocean.com\/blog\/?p=4145&#038;page=2\" class=\"post-page-numbers\"><span class=\"page-num\">2<\/span><\/a><\/nav>\n","protected":false},"excerpt":{"rendered":"<p>\u5317\u4eac\u65f6\u95f46\u67084\u65e5\u65e9\u95f4\u6d88\u606f\uff0c\u8c37\u6b4c\u5468\u4e8c\u53d1\u5e03\u4e86\u4e00\u4e2a\u65b0\u7684Chrome\u6d4f\u89c8\u5668\u6269\u5c55\u7684\u6e90\u4ee3\u7801\uff0c\u53ef\u4ee5\u65b9\u4fbf\u7528\u6237\u5bf9\u7535\u5b50\u90ae\u4ef6\u8fdb\u884c\u52a0\u5bc6 <a href='https:\/\/www.icocean.com\/blog\/?p=4145' class='excerpt-more'>[&#8230;]<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[31],"tags":[63,1425,3972,169,3938],"class_list":["post-4145","post","type-post","status-publish","format-standard","hentry","category-email","tag-google","tag-pgp","tag-3972","tag-169","tag-3938","category-31-id","post-seq-1","post-parity-odd","meta-position-corners","fix"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/4145","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4145"}],"version-history":[{"count":3,"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/4145\/revisions"}],"predecessor-version":[{"id":4150,"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/4145\/revisions\/4150"}],"wp:attachment":[{"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4145"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4145"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.icocean.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4145"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}