Why is it necessary to work with deterministic IDs for Whisper key generation?

[kdeme]

The default Whisper API in geth and also the Whisper V6 JSON RPC interface works with the generation of random identifiers to track stored asymmetric and symmetric keys (aswell as subscribed filters).

In the Status Whisper fork this is (sometimes) changed to generate a deterministic ID. E.g.:

status-protocol-go/vendor/github.com/status-im/whisper/whisperv6/whisper.go

Line 580 in 65edcb1

id, err := makeDeterministicID(common.ToHex(crypto.FromECDSAPub(&key.PublicKey)), keyIDSize)

I guess it is done because higher up in the code the IDs are not stored but the private keys are.
This call + comment seems to confirm that:

status-protocol-go/transport/whisper/whisper_service.go

Line 33 in 65edcb1

func (m *whisperServiceKeysManager) AddOrGetKeyPair(priv *ecdsa.PrivateKey) (string, error) {

Now, I think the whole idea of doing the key management in the Whisper module is so that you would not have to keep pass around and keep on multiple locations the private keys. However, this change compared to the original tells me that this is exactly what is being done here. So I would question why are we using this system in the first place then?
Is it purely a geth inheritance that got annoying to work with so it got hacked around?
Should it not get cleaned up properly then? Or can we work with actual IDs and not the keys themselves?

Furthermore, there seem to be some locations where makeDeterministicID is being used but some where not, I guess depending on whether the calls are actual used?

• status-protocol-go/vendor/github.com/status-im/whisper/whisperv6/whisper.go

  Line 663 in 65edcb1

  id, err := GenerateRandomID()

• status-protocol-go/vendor/github.com/status-im/whisper/whisperv6/whisper.go

  Line 718 in 65edcb1

  id, err := GenerateRandomID()

• and so on...

[kdeme]

By the way, I ask this in the context of the Status - Nimbus integration. As it is one of the items I noticed as being different, and thus a change I need to add.

This adds to the point once made where re-implementing everything from the bottom up will just once again make you inherit any legacy.

[adambabik]

@kdeme I actually don't know the answer for this question from the author of the code so I can only share my assumption which are close to what you described.

I think that deterministic IDs for private keys was added purely to avoid storing the same private key multiple times which reduced the memory footprint. I consider this part to be a legacy and a hack.

However, I also don't quite understand the original intention of using random IDs for private keys. The only thing that comes to my mind is obfuscation and traceability in case the filter ID is leaked.