As a crypto design, this seems like the worst of all possible worlds. Due to what appears to be a platform limitation, public key encryption for push messages apparently has to use RSA --- modern cryptosystems avoid RSA as an egregious source of foot-cannons --- and for some reason the designers have opted to layer ECDSA --- elliptic curve's biggest source of foot-cannons! --- on top of it.
Since Google has excellent crypto people on staff I'm sort of left wondering what I'm missing.
At least it's using Tink, under the hood. If you're unfamiliar with all this stuff, a better starting place might be Google's Tink project.
Looking at the github demo (https://github.com/google/capillary), it seems to me that it they may have decided to use RSA and ECDSA due to limitations of the Android Keystore. I'm no Android developer, though, so I may be misinterpreting something.
I'm currently building a side project I'd like to release for public use at some point, and I'm using PGP/RSA (soon-to-be ECDSA pending some cross-platform experimentation) for multiple-recipient encrypted messages. What makes ECDSA such a foot-cannon?
Caveat: I know enough about encryption to never roll my own.
A foot cannon is a joke term for something which makes it easy to "shoot yourself in the foot". In other words a tool which is easy to use incorrectly.
I think people are very familiar with "foot gun" which is quite common, and are inferring that since a cannon is a really big gun, a foot cannon is a really big foot gun.
It is worth noting that they also provide Web Push encryption as an alternative, which I guess you might like more. Of course having people choose between two options is not great either, so there's that.
So now they have half a dozen messaging apps. Why does Google love building messaging apps? They probably could use better person to person communication instead to consolidate them. Messenger, Hangouts, Alto, duo, etc
End-to-end encryption but "not designed to support peer-to-peer messaging and key exchange"? This sounded like such a good idea, but after reading just realistically looks like vendor lock-in and trying to capture "E2EE" hype.
For those looking for an actual solution, we've built tools (already running in production) that make this very easy:
After looking at this it appears that you are just using this thread to promote a library that doesn't really fill the same problem space but does have a couple of buzzwords in common.
It has, MIT/ZLIB/Apache2 licensed, a library for syncing data, including a relay server if needed, and tooling to a abstract the encryption and key management, plus it is designed from ground up to handle P2P uses. Have you checked the rest of the docs and the repo? What is it missing?
Am I missing something? End 2 end implies client to client, no server access to keys...doing server to client with full key access isn’t even a particularly hard problem, the tough part of most e2e systems is the ECDHE exchange, that’s where I thought this was going.
This looks like e2e push notifications but has warnings against p2p use, so I'm not fully sure what the use case is for this. Apologies for my ignorance - maybe someone can explain this relative to GCM, FireChat, XMPP, or Signal?
By default, both Google and Apple can read the content of messages over their respective push services.
This allows a service to send push messages to its users without Google being privvy to the content of the messages. I guess it's not ready for P2P use yet (aka encrypting the messages with a key unknown to $Service) but could still be useful for telling a user that "Jane sent you a message" without leaking the fact that John is communicating with Jane.
So if I have signal on iOS configured to use notifications (which include the body of the message), those notifications are sent unencrypted over apple’s push notification system?
Some quick googling let me to this SO answer [0] suggesting that as of 2016 devs can configure APNS as an encrypted channel where the client decrypts notification payloads locally.
Your link is correct -- Apple recently added the ability to programmatically modify the contents of push notifications which would allow one to build E2E on top of APNS. Android has always processed notifications through intents, so it's always had this capability. Google is just providing a pre built solution that works for some use cases but this method was technically possible before.
I've read from the Signal team before (no reference links on hand, sorry) that Signal servers send an empty push notification to your device to wake it up, at which point the Signal app fetches your notifications/messages from Signal's servers.
At least, that's what I read for Android/GCM, I'm not sure if that applies to Apple.
I believe they’re referred as “Silent notifications” on iOS. It’s very convenient to update state in the app without having to wait for the user to perform the action manually.
Which would be consistent with most messaging apps that use notifications. Although I'm sure there is an exception to the rule most only use notifications to indicate to the client that a new message is available on the server.
Since Google has excellent crypto people on staff I'm sort of left wondering what I'm missing.
At least it's using Tink, under the hood. If you're unfamiliar with all this stuff, a better starting place might be Google's Tink project.