
End-To-End – OpenPGP Chrome extension from Google - gbarboza
https://code.google.com/p/end-to-end/
======
zx2c4
Notable aspects --

Looks like they're taking it seriously:

"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."

Should be an interesting trove of JS tricks:

"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."

~~~
letstryagain
Well if you're encrypting your email on your local PC and an attacker can
conduct a side-channel attack then you're boned already. Your PC must be
secure to begin with otherwise no crypto is going to save you. If an attacker
can side-channel this encryption then he can probably just straight-up read
your keystrokes or hard drive.

~~~
DSingularity
Why do you say this? I dont think all side channel attack surfaces require
local access to the machine.

~~~
letstryagain
Can you give me an example that would be relevant here?

~~~
mentat
How about BEAST or CRIME?

~~~
cornholio
BEAST is a design bug, insecure use of CBC mode. CRIME is a side channel
attack, but the side channel that leaks information (compressed cleartext
size) is not related to the language used, but again to the design of the
algorithm.

The basic idea is that implementation-related side-channel attacks, such as
timing and power draw, are very hard to exploit remotely. I guess you could
write a JavaScript implementation of AES that is so bad that key-dependent
multimillisecond jitter can be measured remotely. But it's almost impossible
to do it by mistake.

The real problems of JavaScript are it's highly malleable runtime that offers
no guarantees, everything is writable. So you need to improve browser support
before you can write JavaScript crypto, that's why this is a great project:
Google has the ability to change Chrome into a secure end-to-end platform,
should they want that.

~~~
FooBarWidget
Maybe power draw is hard to exploit remotely, but Remote Timing Attacks are
Practical (Brumley & Boneh, Stanford, 2003):
[http://crypto.stanford.edu/~dabo/papers/ssl-
timing.pdf](http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf)

------
panarky
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 DOM or context with unencrypted data.

~~~
dfc
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?

~~~
cryptbe
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 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.

~~~
indutny
Have you guys took a look at
[https://github.com/indutny/elliptic](https://github.com/indutny/elliptic) ?

~~~
cryptbe
Oh we haven't. Looks like it's a nice library. One question: it seems that you
use the message directly, instead of its hash, in ECDSA? [1].

[1]
[https://github.com/indutny/elliptic/blob/master/lib/elliptic...](https://github.com/indutny/elliptic/blob/master/lib/elliptic/ec/index.js#L110)

PS: were you the guy that won the CloudFlare's HeartBleed challenge? great
work :-).

~~~
indutny
I do expect users to hash the message before passing it to ECDSA, this way you
could use any hashing library with it. Though, elliptic.js does actually
depends on hash.js to seed it's PRNG.

Thank you!

~~~
cryptbe
> I do expect users to hash the message before passing it to ECDSA, this way
> you could use any hashing library with it. Though, elliptic.js does actually
> depends on hash.js to seed it's PRNG.

I think this isn't a good design because most people won't know that they must
hash the message before passing it to the ECDSA. People will misuse it, and
open themselves to attacks.

What you can do instead is to pick the right hash based on the curve, like
what we did in End-To-End: [https://code.google.com/p/end-to-
end/source/browse/javascrip...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e/ecc/ecdsa.js#43).

~~~
indutny
Anyway, it would be interesting to compare speeds of our implementations. I'm
really obsessed with try to reach 1ms verification, but so far only got to
4ms.

------
opendais
"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."

I hope that has more than a FAQ warning when they release it to the Chrome
Store. Otherwise....:/

It isn't perfect but it is probably the best in-browser option given the
constraints available.

~~~
tlrobinson
Does this also mean parts of memory containing, say, passwords could be send
to Google?

~~~
latj
This "end to end" encryption happens in the browser. Google is the browser.
Google dont need your keys, they have the plain text.

~~~
AJ007
Also, other browser extensions may be able to access what is going on in the
browser. So Google and (insert list of other parties.)

~~~
woah
Other software on your computer might as well. Or people walking by in the
hallway. So Google and (insert everyone in the world).

------
tokenizerrr
Just tried this out and it works great! Had to build it using the instructions
on the wiki, but nothing too painful. It doesn't just integrate with gmail,
but more with all textarea's around the web. When you are typing in a textarea
and press the extension icon next to the hamburger menu it will pop open a
menu containing the text that you were typing on the site, and are given the
options to encrypt/sign a message. When done it replaces the contents of the
textarea on the site with the signed/encrypted message.

It works quite nicely, and I like it. I would like to see some kind of keybase
integration, though it's not hard to import my tracked users into the
extension by exporting my gpg keyring and importing it again.

edit: It seems that the keybase website does not like messages created by this
extension. [https://github.com/keybase/keybase-
issues/issues/752](https://github.com/keybase/keybase-issues/issues/752)

~~~
mapgrep
But as I'm typing, Gmail is saving my draft automatically to Google servers.
Normally, at least. This means Google would have a copy of my email as it
existed before I encrypted it.

In your testing, do you see any evidence that this extension prevents Gmail's
automatic draft saving?

~~~
magicalist
In the FAQ they mention _" 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."_

I'm curious about this too. Does that mean they somehow insert a textbox that
the host page can't see? I didn't realize extensions could do that.

Edit: ah, this appears to be where it happens. They insert an iframe the
extension owns, so the host page won't be able to see what's in it:

[https://code.google.com/p/end-to-
end/source/browse/javascrip...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e/extension/ui/glass/glasswrapper.js#68)

~~~
sirdogealot
But when displaying the cleartext of a previously sent email or received
email... they must be able to decipher the encrypted text in order to display
it to the viewer, no?

~~~
lmm
Sure, the extension can read the encrypted text from the DOM. But it then
displays it in an iframe which the original site doesn't have access to.

------
unbehagen
If it is a chrome extension and is installed via the Chrome Web Store, it can
be updated silently in the background if I'm not mistaken. So in theory,
wouldn't it be possible to serve Google with a NSL and force them to silently
push a modified update to a targeted user that reveals the private key?

~~~
davelesser
This scenario has been reported to Google as a "bug". Google's response, as of
the time of this writing, is:

    
    
      I don't have further comment for now, but we hear you :)

------
dfc
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?

~~~
orik
Why would attachments be considered part of the body?

Encrypt them before uploading them, and send the decrypting key in the body.

~~~
tlrobinson
Because as far as the email protocol is concerned attachments _are_ part of
the body, just wrapped in a multipart MIME message along with text body.

But Gmail itself may handle attachments differently.

~~~
john2x
> But Gmail itself may handle attachments differently.

AFAIK, Gmail handles attachments the same.

~~~
tlrobinson
When it sends them, yes, but this is more what I was referring to:
[https://news.ycombinator.com/item?id=7842868](https://news.ycombinator.com/item?id=7842868)

------
makomk
"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."

So basically, out the box this doesn't interoperate well with non-beta
versions of GnuPG which are what everyone else is using for end-to-end e-mail
encryption. That's annoying.

~~~
zeroxfe
"We’re releasing this code to enable community review; it is not yet ready for
general use."

~~~
makomk
I don't think they're planning on changing that, according to later FAQ
entries generating non-EC private keys is just too slow and it's the use of EC
keys that causes the problem.

~~~
cbhl
s/causes/solves/

------
nilved
Isn't this contrary to Google's goals as an advertising business? If people
are using end-to-end encryption, they won't have cleartext emails to mine, &c.
I need to wonder what the catch is, because there is definitely one: does
Google own all the keys, or does Google secretly own all the keys?

~~~
rakoo
> does Google own all the keys, or does Google secretly own all the keys

The keys are generated by you, stored on your browser's localStorage,
preferably encrypted (their words, not mine). Since it's open source _and_
distributed by Google, I bet many eyeballs will look for bugs, much more than
alternatives such as Mailvelope or WebPG. So, no, I don't think Google will
ever have access to your private key through this mean.

My theory:

\- We're talking about PGP. This will only impact geeks.

\- Google prefers keeping the trust of said geeks by willingly revoking its
capability to read their conversations. One of the primary support of Google
success is said geeks, and it wants to keep it that way.

\- PGP only encrypts the body of an email. The header (ie the metadata) is
still here for Google to collect, in plaintext

~~~
hrjet
> This will only impact geeks.

Geeks email non-geeks. If the non-geeks don't decrypt the messages it's going
to be all greek to them.

So the more easy they make it for geeks, the more they are pushing non-geeks
to adopt as well.

~~~
x1798DE
It's not really possible to send encrypted messages to people who aren't
already using OpenPGP, since you need to get their public key, before you can
encrypt the message. You could presumably encrypt it with some symmetric
cipher ahead of time, then send them the encrypted junk and say, "Send me a
PGP key and I'll send you the passphrase for the message!", but I dunno that
anyone's going to do that.

That said, pretty much every message I send to someone who doesn't have a key
on the keyservers includes, "Hey, send me your PGP key, I don't do plaintext."

------
1345
Unless I'm mistaken, the author appears to be implementing OpenPGP in
javascript. This has already been done by OpenPGP.js. That project is several
years old, is active, and has been independently audited.

Is this simply reinventing the wheel? OpenPGP.js can easily be used in an
arbitrary browser extension.

I have no affiliation with the OpenPGP.js project besides working on a small
project for personal use.

~~~
declan
Google's posting today addresses this point, I think:

[https://code.google.com/p/end-to-end/](https://code.google.com/p/end-to-end/)
"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... 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..."

~~~
1345
That sounds like NIH syndrome.

~~~
declan
It's possible, but from my conversations with Google engineers in the past I'd
guess (with no inside knowledge) that it was the result of a serious security
evaluation of existing code.

Especially post-Snowden, Google is taking this very seriously. See these
posts, for instance, about TLS weaknesses and implementation of ChaCha20 and
Poly1305 in OpenSSL -- a non-trivial task:
[http://googleonlinesecurity.blogspot.com/2013/11/a-roster-
of...](http://googleonlinesecurity.blogspot.com/2013/11/a-roster-of-tls-
cipher-suites-weaknesses.html)
[http://googleonlinesecurity.blogspot.com/2014/04/speeding-
up...](http://googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-
strengthening-https.html)

Also, the account you're posting from was created 22 minutes ago and has done
nothing but post criticisms of today's announcement. Coincidence? :)

~~~
jacquesm
> Also, the account you're posting from was created 22 minutes ago and has
> done nothing but post criticisms of today's announcement. Coincidence? :)

Declan, nothing but respect for all your writings but he's got to make an
account one day and if he's critical but otherwise polite and seems to be
willing to concede the point why attack like that? It might be an account
created specifically to protect a reputation. As far as I can see his concerns
are valid and the answers are to the point. I'd rather see someone be extra
critical when it comes to new crypto stuff than too lax.

~~~
declan
You're right. In retrospect I was a little too suspicious, and <1345>'s
subsequent comment was perfectly fair.

------
spacefight
This is a push in a great direction. I really do hope it catches on and will
leave to more and more users adopting strong crypto on all ends. One can
hope...

------
riquito
There are javascript implementations of aes, cbc, pkcs7 and more, all released
with Apache 2.0 license. If the quality is what you'd expect from Google they
could become valid alternatives to the other implementations out there.

------
DoubleMalt
This is really great news. But even better would it be if they'd incorporate
it directly in gmail with a polished user interface.

~~~
infogulch
No it wouldn't be better. You'd just have yet another LavaBit that claims
ultimate security but has no teeth. The private keys must _never_ touch the
DOM, whether it comes from Google's servers or put there by an extension,
otherwise it's vulnerable to someone hijacking/NSL-ing the gmail session.

Therefore something _must_ be installed on the local computer, whether that
means a Chrome extension that has access to localStorage (like this project)
or some standalone app.

If you're worried about UX, it looks like this project is meant to interface
with gmail specifically, and extensions are able to alter the experience so I
imagine it will be reasonably easy to use.

~~~
DoubleMalt
Well the threat model would rather be that Google is forced to serve a version
of JavaScript to you that leaks your private key. Which is a concern and a
reason why you should rather use a self hosted email client like Mailpile.

If you are concerned about someone hijacking the gmail session you have lost
anyway, as the decrypted (or not-yet-encrypted) text surely has to hit the dom
at some point.

~~~
declan
<infogulch> is correct. I wrote about this in 2007:

[http://news.cnet.com/Will-security-firms-detect-police-
spywa...](http://news.cnet.com/Will-security-firms-detect-police-spyware---
page-2/2100-7348_3-6197020-2.html) "In theory, government agencies could even
seek a court order requiring security companies to deliver spyware to their
customers as part of an auto-update feature. Most modern security companies,
including operating system makers such as Microsoft and Apple, offer regular
patches and bug fixes. Although it would be technically tricky, it would be
possible to send an infected update to a customer if the vendor were ordered
to do so."

Countermeasures to autoupdates include: (a) disabling them; (b) verifying that
the checksum you receive is the same as posted on a number of different sites
unlikely to be coerced into delivering FedGov malware; (c) only downloading
autoupdates from a non-U.S. repository unlikely to be coerced into delivering
malware. And probably many others I'm not thinking of offhand.

But in reality if your threat model is that the NSA/FedGov/FBI/GCHQ/CIA are
already targeting YOU SPECIFICALLY, you probably already have a few dozen
physical bugs that were concealed in your home placed via a sneak and peak
Scarfoesque black bag job the last time you went out for pizza. A hypothetical
court order to force FedGov malware on you specifically via autoupdates can be
contested by the provider (I was the first to report last May that Google was
litigating two non-malware NSL cases pre-Snowden) and in any case is not bulk
surveillance.

~~~
hifier
I agree that such a thread model makes things difficult, however I'd like to
believe that it can be solved for. Regardless, there is value in hiding your
communications from mass, non-targeted surveillance.

~~~
declan
If you're able to completely "solve for" the threat model of
NSA/FBI/GCHQ/CIA/etc. having a serious and persistent interest in you, and
knowing where you sleep at night, my hat's off to you. Few people are that
confident.

~~~
hifier
I never implied that _I_ could! Anyway, my comment was concerning
communications. Physical security is another matter. I must have missed that
portion of your OP.

------
thomasahle
With the risk of sounding fanboy, this is really fantastic! This could
actually be a viable, secure answer to mail encryption.

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."

~~~
CPAhem
This seems like a fantastic idea. We currently use Syncdocs [1] to encrypt our
Google Drive folders. It is also end-to-end encryption, but it uses AES, not
PGP, which means the key exchange is separate.

If the email is drafted online, do the drafts get deleted and wiped after
encryption on the Gmail server?

[1] [http://www.syncdocs.com/google-drive-encryption-
faq/](http://www.syncdocs.com/google-drive-encryption-faq/)

------
e12e
Between all the build tools that are available -- one would think that'd
they'd been able to settle on one (or at least supply a shell script) rather
than having us cut and paste?

[https://code.google.com/p/end-to-
end/wiki/BuildInstructions](https://code.google.com/p/end-to-
end/wiki/BuildInstructions)

Still, that aside, really exited about this project.

Disappointed with the secondary support for RSA/DSA (ie: pretty much all
existing keys) -- sadly Google never were very good at interop with others :-/

As I understand it, everyone _not_ using this/gmail now have the option of not
being able to communicate securely with the people that start using this; or
running unsupported versions of GnuPG :-/ (Or trying to explain how to
securely generate, export and import RSA/DSA keys into end-to-end -- somewhat
defeating the whole usability benefit...)

------
adrianlmm
What about search and indexing?

Will GMail be able to find those encrypted e-mails when I search for them?

~~~
ikawe
Google _is not_ a privacy company. How can they show you context relevant ads
if they can't read your email? So this will probably never happen within
Google for political reasons.

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](http://www.cs.berkeley.edu/~dawnsong/papers/se.pdf)

~~~
jacquesm
> Google is not a privacy company.

Well... they are and they aren't.

Google has a real interest in protecting the privacy of their users _from
anybody but Google_.

------
plg
Kudos to them for doing it even though it goes directly against their business
model (mining your information). I guess they're betting that the vast
majority of people won't use this.

------
tigerweeds
how is this different from Mailvelope?

------
dave1010uk
This is Open Source and will get lots of peer review. Chrome isn't.

Is there any security advantage in End-to-End bring Open Source when Chrome
isn't? To assume this is secure, you have to trust Google's software isn't
vulnerable or compromised in any way.

Note: I guess this extension will run on Chromium too, which is Open Source.

------
mindstab
Eleanor Saitta (@Dymaxion) had a few things to say about this on Twitter:

On the one hand, I'm happy Google is trying to make GPG usable within GMail:
[https://code.google.com/p/end-to-end/](https://code.google.com/p/end-to-end/)
. On the other hand, this leaves many ?s It sounds like all you get from "end-
to-end", other than a name that's going to cause horrible confusion, is a bare
mininum of GPG functions. No TOFU, no pushing users to encrypt by default, no
better management of keys, no attempt to stop metadata surveillance. It's good
GMail users will have an easier time with GPG, but if it keeps them on a
broken-by-architecture centralized service, we all lose. This doesn't seem to
go far enough in making crypto usable (no indexing solution, for instance) but
it will slow development of alternatives. I admit Google is kind of in a bind
here - if they want to help GMail users, they're also necessarily slowing the
evolution of a safe net. Mostly I wish they hadn't called it "end-to-end".
Because, you know, words mean things, and like "Off the record", that means
something else. I'm surprised Google weren't willing to spend the internal
security resources on end-to-end to be able to stand behind it at time of
release. All told, it pretty much smells like "keep engineers happy" \+ "win
points with the net freedom community as cheaply as possible." Google, if they
wanted to, could do some pretty revolutionary stuff in the secure comms space,
but that would cost actual cash. Ssh, no one wants to talk about how Silicon
Valley business models depend on surveillance.

[https://twitter.com/Dymaxion](https://twitter.com/Dymaxion)

------
drdaeman
Nice. While they're at it, maybe they'll revive gpgAuth, so maybe we'll
eventually have a sane and useable PKI-based auth on the web?

Oh, and maybe having PGP's WOT for use by the websites would be nice too.
Could provide distributed "likes" by PGP-signing, without any central
authorities.

------
mentat
A current real alternative that uses native binaries to avoid the JS issues is
WebPG[1]. I've been using it for about a year and while it has its rough
edges, it's a pretty solid tool (and approach).

1\. [https://webpg.org/](https://webpg.org/)

------
mike-cardwell
Can anyone tell if this addon has been built in a suitably abstract enough
manner such that the core can be used to build similar extensions for other
browsers? I.e, would it be possible to take this code and wrap it in a Firefox
extension?

~~~
reitanqild
Seeing that you haven't got a reply in three hours here's what I found:

There is mentions of using Closure which is a google JavaScript technology. I
think however it is cross browser.

------
cvwright
Very cool! I'm assuming this is not just for sending PGP mail, but also for
decrypting PGP-encrypted mail that the user receives.

Has anyone been able to tell how they protect against the server grabbing the
plaintext after it's been decrypted?

------
mox1
I worked at a company who has a very similar product,

[https://www.penango.com/products/penango-for-
webmail](https://www.penango.com/products/penango-for-webmail)

------
josephby
Someone should try using it with this:
[http://sicomail.com;](http://sicomail.com;) automatically encrypts all of
your incoming email.

~~~
e12e
I'm not entirely clear on why it's better that sicomail (potentially) has your
unencrypted emails, than that google has them?

I've thought about setting up something similar as an incoming mail filter on
my imap server; encrypting and signing unencrypted mail to myself -- just to
have data at rest encrypted, and as a motivator for myself to use gpg more
regularly -- but having a third party do it seems a little silly?

------
diasp
Take a look at [http://openpgpjs.org/](http://openpgpjs.org/) OpenPGP
JavaScript Implementation.

------
haarts
If you want to build the extension and your aliases don't work add "shopt -s
expand_aliases" to the compile.sh file.

------
zobzu
itd be cool to have this like
[http://www.monkeysphere.info/](http://www.monkeysphere.info/) between browser
and server, and not rely on CAs.

------
higherpurpose
It doesn't support only NIST curves, does it?

~~~
cryptbe
It supports Curve25519 and Ed25519: [https://code.google.com/p/end-to-
end/source/browse/javascrip...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e/ecc/curve_curve25519.js) and
[https://code.google.com/p/end-to-
end/source/browse/javascrip...](https://code.google.com/p/end-to-
end/source/browse/javascript/crypto/e2e/ecc/curve_ed25519.js)

------
donniezazen
What is the difference between GnuPG and OpenPGP?

~~~
zvrba
OpenPGP is a standard, GnuPG is one implementation of it.

------
moeedm
Encryption. Google. Okay.

No thanks.

------
dotBen
So End-To-End utilizes Elliptic Curve-based keys

Could someone better across current cryptographic trends than I comment on
that choice? We know the NSA has found weaknesses in certain implementations
of elliptic-curve based cryptography in the past, and I was under the
impression there was a preference in the community to move away from them in
general given the unknown extent of the integrity concerns.

~~~
cryptbe
> We know the NSA has found weaknesses in certain implementations of elliptic-
> curve based cryptography in the past

No, we don't.

Even djb wants people to use ECC. Note that End-To-End supports not only
NIST's curves but also djb's.

