91–100 of 173 posts
And this is aawesome too: "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."
Regarding JavaScript crypto: We hold ourselves to a higher standard; we started from scratch and created a testable, modern, cryptographic library. That is awesome. So's this: Chrome’s design means that extensions should be safe against other extensions. And this: 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 DO…
I had a slightly different reaction to the "high standard" bit. I always thought Prof. Boneh was a high standard. Does anyone know if there were any obvious reasons to exclude SJCL?
I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's still Boneh's teaching that has helped my colleagues and me create this library ;-).
SJCL is a great library, but it didn't quite work for us because:
* It isn't a Closure library. We want to use Closure because it supports types, which in turn make it easier and less error-prone to develop crypto code.
* It doesn't support typed arrays. We don't have typed arrays in End-To-End yet, but we're working on that.
* It doesn't support all the curves we want, and it seems that the main developer isn't interested in adding new curves, e.g., Curve25519.
* It doesn't have ciphers or signature schemes that we need such as RSA, Ed25519, deterministic ECDSA, etc.
It doesn't support only NIST curves, does it?
Will GMail be able to find those encrypted e-mails when I search for them?
Earlier quoted context omitted.
I had a slightly different reaction to the "high standard" bit. I always thought Prof. Boneh was a high standard. Does anyone know if there were any obvious reasons to exclude SJCL?
Disclaimer: I contribute to the core crypto library in Google End-To-End. I was also a student of Prof. Boneh. I took his CS255, and became a TA for his infamous's Crypto I class on Coursera. So I guess at the end of the day it's still Boneh's teaching that has helped my colleagues and me create this library ;-). SJCL is a great library, but it didn't quite work for us because: * It isn't a Closure library. We want t…
maybe a stupid question, but any reason why not use OpenPGP.js?
Is it even worse for your case than SJCL?
No thanks.
What about search and indexing? Will GMail be able to find those encrypted e-mails when I search for them?
The FAQ states: > Only the body of the message. Please note that, as with all OpenPGP > messages, the email subject line and list of recipients remain > unencrypted. Hopefully attachments are considered part of the body?
It depends on whether they use PGP/MIME or inline PGP. Without installing the tool, I'm guessing they use PGP/MIME, because you pretty much can't use html email with inline PGP, and I doubt they're going to default to plain/text mails.
This is really great news. But even better would it be if they'd incorporate it directly in gmail with a polished user interface.
End-to-End is better outside Gmail. Because it is an extension, you can encrypt/decrypt any message in any webpage such as: web forums, other web mail providers (yes even Yahoo Mail, Outlook.com, etc), or your custom internal SquirrelMail or Outlook Web Access instance, etc. Its open source can be reviewed by third parties, it can be built and installed locally, with no dependency or trust placed in Google's online s…
Google has made this a fucking nightmare. Every time you start Chrome, you get an annoying popup "do you really want to enable local extensions blah blah"
What about search and indexing? Will GMail be able to find those encrypted e-mails when I search for them?
But even for technical reasons, it's probably a ways off. Doing encrypted search is a whole other problem on top of encryption. You can't just apply standard search out of the box. Given that Google is just now unveiling an encryption solution, I would not expect GMail (or any google service) to release services built on top of them for a while, even if they wanted to (which they don't).
Unless you are doing hashing and comparing a specific value exactly (e.g. how you would securely store a password hash in a DB) there is no general purpose text indexing package that I know of.
There is some academic momentum on encrypted search: http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf