Project Capillary: End-to-end encryption for push messaging, simplified | Hacker News Reader

Project Capillary: End-to-end encryption for push messaging, simplified

android-developers.googleblog.com

129 pointsKAMSPioneer33 comments

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.

Okay I Googled "foot-cannon" but didn't find any relevant looking results. Can you explain to me what it is?

a more extreme foot-gun (this term should be more easily googleable)

A way of catastrophically shooting oneself in the foot.

A tool which is easy to accidentally misuse in ways that seriously harm yourself.

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.

Why is this term so familiar to people on HN but like OP I cannot find a single reference to it on Google...

I think "foot gun" (https://en.wiktionary.org/wiki/footgun) is more common.

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.

A firearm 12" in size

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.

Since they are supporting up to KitKat 4.4 that seems correct. But why wouldn't they also use a shim?

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.

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.

What's the preferred asymmetric encryption option here then?

http://latacora.singles/2018/04/03/cryptographic-right-answe...

TL;DR: Use NaCl, or libsodium, or the go equivalent (https://godoc.org/golang.org/x/crypto/nacl).

> (at last, the Google privacy team has its own messaging app!)

A nice jab at themselves. Glad they have a sense of humor.

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

It was a joke. The app in question is a demonstration of their secure web push protocol layer. It's not a product.

Google actually has an internal social network and the main purpose is basically to make fun of google's messaging apps.

It's not just for that. They also post screenshots of other social networks referencing its meta-memes.

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:

http://gun.js.org/docs/SEA

- Cross-device, cross-platform.

- Fully P2P/decentralized.

- `user()` provides key management, multi-device login.

- ECDSA

- Diffie-Hellman

- Can do RSA-like DH-based 1-way messages.

- PBKDF2

- AES

- SHA256

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.

Thanks, that clears things up a lot more.

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.

[0] https://stackoverflow.com/questions/32719476/how-secure-are-...

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.

Not sure what Signal does here particularly, but their FAQ claims it's not a problem. https://support.signal.org/hc/en-us/articles/217524107-Can-G...

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.

Reply on news.ycombinator.com