Open Security Issues

The purpose of this thread is to discuss and collate security issues with no concrete plan for resolution. Kind of like a github in this great forum.

I feel we should discuss any percieved security risks, their severity and propsed mitigations. Please tile your percieved security risk. In addition provide a PSI# (perceived security issue number) in numerical sequence relative to the previous post.

Please follow the format below for easy readability and item discovery.

Relay Chunk Fingerprinting Attack




Uploaded files can be tied back to the content provider. Liability issues may arise.

A resourceful attacker collects offending files/data (music, movie, games etc) from various sources online then generates a growing database.

The attacker, acting as a relay node, monitors chunks uploaded by clients connected to it.

Using a clients Public Key, an attacker could use the very same convergent encryption method used by maidsafe.

The attacker uses the target clients Public key to self encrypt the files in the database of offending data. If any of the resulting chunks match the chunks that passed through the attackers machine while acting as a relay, the uploader can then be held liable.

Onion encryption/tunneling.
After the initial self encryption is completed, a node other than the relay (lets call it node 3 ) provides the client with its Public key via an encrypted message. The client then further encrypts each chunk with node 3s’ PK. The upload commences and the malicious relay is left with nothing useful.

Please respond by first including the the PSI# in bold characters. Linked replies on discourse usually only have a picture/icon associated and require a click to expaned the post that is being responded to. It’s IMO tedious and not as easy for browsing.

1 Like

Been told these will not exist in the later versions.

I thought this is what is going to happen. The chunk being uploaded is encrypted. Not sure why the client’s public/private key would be used for that encryption.

1 Like

I wasn’t aware these changes were in place. That closes this issue for me. Will update my post.

Anyone else have any seeminly open security issues they’d like to report?

I still like this confirmed as there have been changes to the changes in other areas.

1 Like

What is a relay node? A clientmanager persona of a vault node?

1 Like

A while ago this was a node that acted as the node a client talked to and it relayed the messages to the first section.

In alpha 2 IIRC the client connected to one relay node only and the idea was that there would be multiple. But more recently it has been said that there will not be relay nodes.

But that was before so much work has been done and it would be good to have some confirmation by a team member or someone who knows the current mechanism.


Changed status. Awaiting confirmation from @maidsafe

1 Like

No more proxy nodes after alpha 2 They were used to rate limit and more, but because we owned them. It would not be possible to do that in the real network.

No we have this

clients ----connect to -----> Vaults (the Elders of the section this identity (pub key) belongs to)

With vault phase I we will have

clients —connect to ----> A single vault representing the whole network [this allows us to test the client and vault code without routing)

Then we have

cients —connect to ------> A single network (no sections) and this allows us to also test much of routing.

Then Fleming :wink: which is a network of many sections.

I was explaining this recently. Just think clients speak to vaults, they don’t care if it is a single vault or many of them. So a client -> vault relationship is enough for client.

Vaults on the other hand do care as a single vault does not scale, so we add in routing. However we only add routing to vaults, no need to confuse clients with all that complexity. So easy way to think is routing decentralises the vault and it simplifies the picture. It also means we can much easier test locally with just a single vault and many clients. So not mock routing any more just local network.

This buys us much more speed to launch and also buys devs a much better local test network :wink:


@dirvine, thank you for the explaination


Simplicity on front end and complexity in back end - Love it!!!


In terms of personas, the vaults’ persona a client will connect to is still the “ClientManager” persona, correct? (I am asking about the situation at launch of the real safenet, not intermediate alphas, betas etc.)

Yes well the client manager is only the src Elders now. So the Elders closest to the client identity. For now we have shrunk all personas to Elder Adult Infant, Elders do most of the admin, Adults most of the heavy lifting managed by Elders and Infants, well not much at all right now.


So let me get this right. The client connects to its close elder (singular or plural?), then the close elder forwards (relays) the client’s traffic its destinations. From my understanding the close elder provides the public key for encryption. If so, what prevents the close elder from carrying out the above fingerprint attack?


The client signs with it’s key any request. The Elders then agree this is valid and sign as a group (via PARSEC/BLS). The client connects direct via TLS 1.3 to those Elders (not forwarded).

Clients do not use their public key to encrypt etc.

I am not sure what the “fingerprint attack” is referring to. But in any case here is some info.

The Elders scrub the IP etc. so beyond that we don’t know the client endpoint.
If there is a malicious Elder they will see what the client is uploading/downloading (at the moment anyway).

Don’t know if that helps or not?

Attacker gets their Node to Elder status and then checks all chunks looking for or recording the hash of the chunk to know who is uploading what for those connecting to the elder.

The elder is looking for specific chunks that they determined from self encrypting the files they are looking for


Yes, this is currently possible. Of course the Elder may not have any clients from its country etc. connected, but it may.

As we move on (post beta) then even this can be placated, but right now best to assume this is possible for previously known data.


So the issue remains open. Any mitigation ideas off the top of your head?

1 Like

Chunks IMO must be encrypted with a key derived from a distant group.

1 Like

Several, first though frame the attack, it is only previously known data, so more a rainbow type attack.

Much of these kinds of things can be placated (and I won’t spend time here as I am forcing a big push to full working network to let folk see the whole thing) by allowing relay through anonymous id’s. So a Client encrypts a request to remote section using the sections key to encrypt the request which is relayed back to the client who can decrypt the response (that is encrypted via it’s anon id).

There are many ways to do it IMO, but right now I am looking to get the simplest possible release and honestly don’t wish to take Engineers minds into these areas until we have the whole network.

For instance personas have been simplified, connections simplified and so on to get us to feature complete. Otherwise we get folk in a silo thinking of only one solution based on the lib they are working on. When the whole network is in place then it is really easy to seal up the edges. It’s a tough one as I am almost forecful in keeping folk on getting all the basics in place.

There are a few small/edge case things like this we could list, but my fear is “sorting” these before the network exists. After it exists these are much simpler to explain (and code).


For sure that is a valid approach. Prob the simplest (so likely best). But I think there are a couple of things related to this that can all be covered with very slight changes to the client connect model