whisper, private keys on server

security

#1

Hello Again All. I understand that infura will not host whisper nodes because of security concerns. Specifically the private keys are generated and stored on the server. To me this seems to be a limiting aspect to the whisper protocol. Is there anything status is doing to mitigate this? Will this be addressed in upcoming versions of whisper.? Should I ask this or open an issue in github? I am asking because we would like to use whisper as well, but it has real value once many nodes are enabled to use whisper IMO. Should nodes be incentivised to run whisper and some how lock down the keys?


#2

Hello. I believe we’ve discussed today this topic at our bi-weekly dev meeting. Can you elaborate more on what is your use case for whisper?

From my perspective, having a need to store private keys for whisper is not a limitation of whisper protocol in any way. It’s rather an essential part of any communication through whisper. You need a key to encrypt and decrypt messages, and, if we talking about asymmetric encryption, your key is basically your identity in this messaging system.

Of course, it’s possible to host a whisper node somewhere and use any sort of remote API to send/receive through this node, but that’s something that can be built easily with existing code and libraries. There is no need to change Whisper spec or Web3 protocol for that from my point of view.


#3

@ebadiere if I understand correctly, and @divan correct me if I am wrong, Infura concern is a valid point from their perspective.

my assumption is that they want to offer whisper nodes to clients, so that clients don’t have to run their own (so not just for relaying messages but also for posting messages).
If a client would like to send a message at this point, it is true that it would have to create a private key on the remote server and then call shh.post using the keyid returned. So in this scenario I would understand infura concerns.

In status we follow a very different approach. We run a whisper node on the client, so your private keys are stored encrypted on your device and are never sent across the wire/allowed access from remote.

I won’t go into whether it is a limitation or no as it’s quite subjective and more of a matter of intended usage etc


#4

Just to make sure we’re on the same page, what is proposed here is to have “thin” clients (dApps) to Whisper nodes, right?

I think both private and public key plays important role in the Whisper design:

  1. Whisper node doesn’t have any metadata in messages, so it tries to decrypt them (with or without using topics/bloom filters mechanism). To do so it has to own private key.
  2. Whisper is a messaging solution. Messaging usually implies sender and receiver(s), which have to be somehow identified between each other. In Whisper public key plays this identification role. If you want to send a message to me, you send it using my public key.

So, essentially the problem boils down to the fact that Whisper designed as one identity per node. I believe it’s possible to implement a design where Whisper node maintains a pool of identities, use their keys and provides handy API, but this should be aligned and agreed with original whisper designers. There are also clear drawbacks – performance impact (probably huge, as it’ll have to decrypt messages for multiple keys), security concerns (keys are still in memory, side-channel attacks, etc) – and they must really underweight the benefits from this design.


#5

we are definitely not on the same page :slight_smile:
whisper nodes can have multiple identities (addPrivateKey can be called multiple times, and then you can get messages for multiple keypairs), or we are talking about 2 different things?


#6

whisper nodes can have multiple identities ( addPrivateKey can be called multiple times, and then you can get messages for multiple keypairs), or we are talking about 2 different things?

Hmm, you’re actually right. It’s just for Status we always use SelectKeyPair, which removes all other keys and ensures this selected key is the only one used for decryption. So I’ve never actually tried Whisper with multiple identities, hence this false assumption about Whisper.

Have anyone tried it btw? What was the initial thinking for having multiple private keys per node? It was probably a different use case from what we’re discussing here.


#7

I think the idea of whisper is that you run your own client, rather than offloading that to some infrastructure (Infura for example), it seems to be the way it was meant to be used, not sure about the use case, but given the design of whisper why not? might have been the reason :slight_smile:


#8

You add a key (symmetric or asymmetric) to Whisper and then create a filter with the key ID. Whisper has no notion of identity actually, there is no “main key pair”, all added keys are equal.

I think a remote Whisper node similar to Infura service is possible but as it was discussed during the last Core Devs Meeting, new APIs are needed to send and receive messages. Also, it seems like this would only please people using MetaMask, doesn’t it? I still don’t get the reasoning behind this. If I were heavy DApps user, I would definitely run a node on my laptop. If not, use Status Node :slight_smile: It supports Infura + gives a Whisper node. Such a combination is not possible with geth, that’s pretty unique and we should advertise this IMO.

Whisper is so lightweight that when geth switches to libp2p, I believe it will be possible to run it in a browser just like currently a MetaMask extension. The bad thing though is that the community assumes that there will be a single entry point for all services: Ethereum, swarm, IPFS, Whisper and others. I am not convinced that should be a case. Geth becomes a monolith and it’s been proven that monolith approach is doomed.


#9

Okay, I finally tracked down where my confusion came from. This is our patch that adds SelectKeyPair to whisper package, and I always assumed that’s the part of the original Whisper design.