Can someone give an explanation of how this works?
In order to get this to be seamless, I would guess that this only works when you are sending from one yahoo account to another one correct? Unless they have found a clever way to share the public keys.
Yahoo Paranoids Engineering Director for end-to-end here.
Today our extension works as a developer only demo, and no Yahoo keyserver service is online yet. If our toy keyserver code didn't make it into this release, you will see it very soon and will be able to experiment.
We released the source so we can solicit security feedback early, and can keep all security and privacy critical parts of this product in the open. No "just trust us" now or in the future.
Along those lines, we will work with industry peers to build public key registry software that interoperates with other federated providers, is open source, and is transparent in the cryptographic sense. I.e. Yahoo and Google users should be able to send encrypted email to one another with ease, and if either company was forced to lie about the public keys of our respective users we would be caught because math.
There's a lot more in the works, and we have many challenges to overcome to make this generally usable. In addition to the key server, there's not unnecessarily breaking existing mail features, multi-device issues, search over encrypted content w/o providers being able to read it, and mobile support to start.
If you know anyone with the skills and motivation to make strong, usable encryption available at internet scale we'd love to listen, collaborate, or hire. :)
I do know a team whom you should work with: keybase.io
Keybase.io have an early-level product which would help with your keyserver issue. It has a CORS-enabled API, a commandline tool, an online interface for encrypting, signing, verifying, etc. and a "ring of trust" tool that follows the modern social network model (where, you can "track" somebody and it auto-signs their keys each time they upgrade.
When you release the keyserver, please make sure that CORS is enabled. I'd love to add it to PublicKey.js[1]. Even better would be for it to gossip to the SKS pool. That way, gpg --recv-key would work to get Yahoo users' public keys.
Except that we cannot verify that you actually deploy the "open" code. It's obviously commendable that you do development in the open, and have people review the work you do. But there is no way for us to know that you don't run /addNSAbackdoor.sh in your deploy script for key parts of your infrastructure.
All encryption runs clientside. The whole point of end-to-end is that you don't have to care about who the message passes through.
Your actual worries at this point are the key exchange (impersonation) and extension distribution.
The first is very hard to get right without alienating a large number of potential users, the second seems perfectly possible to have verified but seems like it's going to require some kind of changes in the Chrome extension system.
It doesn't have to pass through anything but if the '/addNSAbackdoor.sh' script just adds a routine to the code that adds the Public Key of an NSA owned key-pair before the encryption process, then the NSA can pick it up from any Internet-tap they have and decrypt it.
Maybe Its time to introduce reproducible buulds to the JavaScript word? So that we can prove that the minified version is the same as the source.. Or just release the code as a nonminified AGPL set of ES6 files. With the coming of http2 it's going to be less of a problem
But I still think we need to think of an out of band way to verify trust. Just like I can verify that my install of gpg or tails is legit
You're in luck! There's a working group called "Subresource Integrity" that's developing a way to allow websites to restrict a resource (including javascript files) to a defined hash.
This is a step in the right direction for embedding external resources. It'd remove CDNs as an attack vector (once it's rolled out everywhere).
It'd be great to come up with some kind of way to also tell the client what resources are expected, and if a new one is loaded (e.g. <iframe src="http://dangerous.malware.com"></iframe>) the client would not even connect to it.
It looks like they forked Google's end-to-end Chrome extension. Best place to look would probably be the docs for google's e2e. https://github.com/google/end-to-end/wiki
In order to get this to be seamless, I would guess that this only works when you are sending from one yahoo account to another one correct? Unless they have found a clever way to share the public keys.