Google invites GMail users to use end-to-end encryption
Google is preparing to release a special Google Chrome browser extension that will allow users of the GMail service to encrypt messages before sending them, in order to eliminate the possibility of intercepting messages. The extension under the simple name End-to-End uses the OpenPGP standard , but is not yet ready for release, as Google is asking for help from the community.
The Google Security team decided to release the source code first under the Apache 2.0 license , before the extension will be published in the Chrome Web Store. The reason for this is simple - Google has had to face a number of difficulties, so the company is not yet sure that their implementation of OpenPGP is reliable. Google notes that JavaScript runtime is not architecturally reliable because it cannot control what happens at the native level, so there is a risk of data leakage. Noting the reasons for the emergence of this project, the company said that GnuPG and PGP currently exist, but they require knowledge of the user in the field of encryption, while the extension from Google will try to carry out the encryption process as friendly as possible. As for JavaScript itself, the Google FAQ gives some explanations.
To fix all the flaws in the design of the extension, if possible, Google includes its new product in the list of available for reward for finding and operating vulnerabilities. Thus, Google’s help is not asking for free, but with the opportunity to receive a reward from $ 500 to $ 20 thousand.
Google also asks users to disable sending anonymous statistics to the company when using the extension, because in some cases (like a browser crash) data may be sent to Google to restore the user's private key.
')
For reference . Earlier on Habré already discussed an example of a similar extension from third-party developers.
The Google Security team decided to release the source code first under the Apache 2.0 license , before the extension will be published in the Chrome Web Store. The reason for this is simple - Google has had to face a number of difficulties, so the company is not yet sure that their implementation of OpenPGP is reliable. Google notes that JavaScript runtime is not architecturally reliable because it cannot control what happens at the native level, so there is a risk of data leakage. Noting the reasons for the emergence of this project, the company said that GnuPG and PGP currently exist, but they require knowledge of the user in the field of encryption, while the extension from Google will try to carry out the encryption process as friendly as possible. As for JavaScript itself, the Google FAQ gives some explanations.
To fix all the flaws in the design of the extension, if possible, Google includes its new product in the list of available for reward for finding and operating vulnerabilities. Thus, Google’s help is not asking for free, but with the opportunity to receive a reward from $ 500 to $ 20 thousand.
Google also asks users to disable sending anonymous statistics to the company when using the extension, because in some cases (like a browser crash) data may be sent to Google to restore the user's private key.
')
FAQ
Once you published the source code, then I could publish the extension in Webstore?
Please, do not do that.
The development team understands that journalists, human rights activists, and others who may not be technically savvy may potentially benefit from this extension, hence this extension can cause unpleasant consequences.
We release the source code in the hope of identifying vulnerabilities that our team might have missed. Therefore, as soon as we receive enough confirmations that our implementation is reliable, we ourselves will release the extension into the directory and provide further support.
Does encryption work with attachments or only with the letter text itself in GMail?
Only with text. Remember also that the subject line and the list of recipients will also not be encrypted.
Why do you use key generation only on elliptic curves?
RSA generation is slower than on elliptic curves .
Will end-to-end work on mobile devices?
At the moment, Chrome on Android and iOS do not support extensions, so no.
What specifications do you use in the extension?
RFC4880 - OpenPGP Message Format
RFC6637 - OpenPGP Cryptography on Elliptic Curves
Unfortunately, the extension does not yet support the specifications for MIME protection with OpenPGP and the Camellia algorithm .
I have kryakozyabry!
We tried to avoid displaying quacking for non-romance languages, but don’t be surprised if you meet kryakozyabra, especially in service areas. We did not implement automatic checks for encodings.
Are private keys in memory, are they cleared after each operation, or is there a cache for the code phrase?
Private keys are stored unencrypted in memory. We recommend that your "keychain" has a code phrase. In this case, private keys are stored in an encrypted localStorage.
Well, how are they protected there?
Since the keys are in localStorage, you need to encrypt them. If the memory is simply unencrypted, then rely only on the Chromium sandbox.
Javascript Srsly?
Yes, when we started work on the End-to-End, all previous JS-libs did not fit us, so we had to pile our own. We are well aware of all the threats that JS has in them for encryption, so we took all the measures that came to our mind to mitigate and eliminate risks .
JavaScript does not support many key cryptography features. Where do without them in encryption?
Modern engines, such as V8 in Chrome, support typed arrays, and WebCrypto provides cryptographic pseudo-random number generator .
JavaScript crypto projects in the past have repeatedly broken, reducing the credibility of the language to implement such serious things.
True statement. But in practice, no common programming language provides 100% protection against vulnerabilities.
We are well aware of all the examples, so from the very beginning we set a high level of quality for ourselves. We started from scratch to create a modern cryptographic lib covered in tests. It provides support for BigInteger methods, modular arithmetic, elliptic curves, as well as symmetric and public-key encryption. By doing this, we developed an OpenPGP shell on top of the library. Part of the library code is used internally by our company in production .
Full FAQ on Google Code .
Please, do not do that.
The development team understands that journalists, human rights activists, and others who may not be technically savvy may potentially benefit from this extension, hence this extension can cause unpleasant consequences.
We release the source code in the hope of identifying vulnerabilities that our team might have missed. Therefore, as soon as we receive enough confirmations that our implementation is reliable, we ourselves will release the extension into the directory and provide further support.
Does encryption work with attachments or only with the letter text itself in GMail?
Only with text. Remember also that the subject line and the list of recipients will also not be encrypted.
Why do you use key generation only on elliptic curves?
RSA generation is slower than on elliptic curves .
Will end-to-end work on mobile devices?
At the moment, Chrome on Android and iOS do not support extensions, so no.
What specifications do you use in the extension?
RFC4880 - OpenPGP Message Format
RFC6637 - OpenPGP Cryptography on Elliptic Curves
Unfortunately, the extension does not yet support the specifications for MIME protection with OpenPGP and the Camellia algorithm .
I have kryakozyabry!
We tried to avoid displaying quacking for non-romance languages, but don’t be surprised if you meet kryakozyabra, especially in service areas. We did not implement automatic checks for encodings.
Are private keys in memory, are they cleared after each operation, or is there a cache for the code phrase?
Private keys are stored unencrypted in memory. We recommend that your "keychain" has a code phrase. In this case, private keys are stored in an encrypted localStorage.
Well, how are they protected there?
Since the keys are in localStorage, you need to encrypt them. If the memory is simply unencrypted, then rely only on the Chromium sandbox.
Javascript Srsly?
Yes, when we started work on the End-to-End, all previous JS-libs did not fit us, so we had to pile our own. We are well aware of all the threats that JS has in them for encryption, so we took all the measures that came to our mind to mitigate and eliminate risks .
JavaScript does not support many key cryptography features. Where do without them in encryption?
Modern engines, such as V8 in Chrome, support typed arrays, and WebCrypto provides cryptographic pseudo-random number generator .
JavaScript crypto projects in the past have repeatedly broken, reducing the credibility of the language to implement such serious things.
True statement. But in practice, no common programming language provides 100% protection against vulnerabilities.
We are well aware of all the examples, so from the very beginning we set a high level of quality for ourselves. We started from scratch to create a modern cryptographic lib covered in tests. It provides support for BigInteger methods, modular arithmetic, elliptic curves, as well as symmetric and public-key encryption. By doing this, we developed an OpenPGP shell on top of the library. Part of the library code is used internally by our company in production .
Full FAQ on Google Code .
For reference . Earlier on Habré already discussed an example of a similar extension from third-party developers.
Source: https://habr.com/ru/post/225147/
All Articles