Hi,
The next few months I want to implement a fix for the pitch black attack. In this email I’m starting by presenting the concrete plan. Introduction ------------ The pitch black attack is a crippling weakness of our friend-to-friend mode which currently enables a single node to take down all of darknet. The pitch black attack was found by the GNUnet folks in 2007.¹ The fix has been known since 2008, but not implemented, because it hadn’t been simulated. In 2016 I completed a simulation (originally started by thesnark) and showed that the fix works.² ¹: http://grothoff.org/christian/pitchblack.pdf ²: https://www.draketo.de/light/english/freenet/mitigate-pitch-black-attack-simulation-works The pitch black attack works by lying in swap requests: Claim better peers than the target to make the target accept your location. But don’t actually accept the location of the other node: In the next swap request you start with the same location again. That way you can slowly but irreversibly drain locations from the network (see the simulation linked above for details). The original plan to fix the pitch black attack was to send a request to a random location and check the distance between the closest node and the key. If the distance is larger than 0.037, then the network is guaranteed to be under attack and we take that location. Recently I discussed the original plan to address the pitch black attack with Florent again, and he found a weakness in the Scheme: attackers could start a competition of veiled almost-same locations. In the discussion we found a more robust fix that has the advantage of only relying on actual performance metrics. The new fix ----------- Regularly insert random data as SSK or CHK and try to retrieve it with a random delay up to the typical lifetime of a key. If it is gone, we take its location. This turns Freenet into a self-balancing graph: If some part of the network becomes unreachable, nodes fill the void. Healing of data which is partially available from cache recovers lost content. Regular swapping returns nodes that took a random location back to a location close to the data in its store, because most of its peers are still located close to the original location. Since it’s unknown who inserted an SSK, attackers cannot target those inserts specifically. Detection of an attack on part of the keyspace becomes based only on actual performance. Alternate between checking SSKs and checking CHKs to prevent attacks on only parts of the store, for example taking up part of the keyspace and having a tiny CHK store, but a large SSK store. Attacks that would still work ----------------------------- - Delete content by taking over parts of the keyspace with nodes which do not swap and at some point shutting them all down. if people kept running keepalive for important files, then most of the important content would actually be in caches and not only at the target nodes, so it could be reconstructed and would get re-inserted the moment they purge their stores. - Delete all old content from those nodes but keep more recent content (but then only old files could be taken down while communication would continue). This relies on the interval after which - Have nodes positioned around the keyspace with a small store and move-swap all others into a very narrow portion of the keyspace. This can degrade performance, but if it is too small, then lifetime will not be guaranteed, so some nodes will detect the attack and fill the space. - Blackhole all requests from a certain part of the keystore to get nodes to leave that part. However they will snap back with further swapping requests, because their peers will still be optimal for that part of the keyspace, or others will fill the void. With this change attackers can still degrade the service, but no longer disrupt it. If people keep running keepalive for important files, then most of the important but infrequently accessed content would be in caches and not only at the target nodes, so it could be reconstructed and would get re-inserted shortly after attackers purge their stores. Keepalive is an official plugin starting with 1487. Frequently accessed content will already be in caches even if people don’t use keepalive for it. Question -------- Do you see powerful attacks on the new scheme that I missed? The next steps -------------- If no crippling weaknesses are found, I intend to implement this scheme during the following months. Best wishes, Arne Hi, The next few months I want to implement a fix for the pitch black attack. In this email I’m starting by presenting the concrete plan. Introduction ------------ The pitch black attack is a crippling weakness of our friend-to-friend mode which currently enables a single node to take down all of darknet. The pitch black attack was found by the GNUnet folks in 2007.¹ The fix has been known since 2008, but not implemented, because it hadn’t been simulated. In 2016 I completed a simulation (originally started by thesnark) and showed that the fix works.² ¹: http://grothoff.org/christian/pitchblack.pdf ²: https://www.draketo.de/light/english/freenet/mitigate-pitch-black-attack-simulation-works The pitch black attack works by lying in swap requests: Claim better peers than the target to make the target accept your location. But don’t actually accept the location of the other node: In the next swap request you start with the same location again. That way you can slowly but irreversibly drain locations from the network (see the simulation linked above for details). The original plan to fix the pitch black attack was to send a request to a random location and check the distance between the closest node and the key. If the distance is larger than 0.037, then the network is guaranteed to be under attack and we take that location. Recently I discussed the original plan to address the pitch black attack with Florent again, and he found a weakness in the scheme. In the discussion we found up a more robust fix that has the advantage of only relying on actual performance metrics. The new fix ----------- Regularly insert random data as SSK or CHK and try to retrieve it with a random delay up to the typical lifetime of a key. If it is gone, we take its location. The frequency of check inserts should be much lower than the frequency of swap requests. This turns Freenet into a self-balancing graph: If some part of the network becomes unreachable, nodes fill the void. Healing of data which is partially available from cache recovers lost content. Regular swapping moves nodes back to a location close to the data in its store, because most of its peers are still located there. Since it’s unknown who inserted an SSK, attackers cannot target those inserts specifically. Detection of an attack on part of the keyspace becomes based only on actual performance. Alternate between checking SSKs and checking CHKs to prevent attacks on only parts of the store, for example taking up part of the keyspace and having a tiny CHK store, but a large SSK store. Attacks that would still work ----------------------------- - Delete content by taking over parts of the keyspace with nodes which do not swap and at some point shutting them all down. if people kept running keepalive for important files, then most of the important content would actually be in caches and not only at the target nodes, so it could be reconstructed and would get re-inserted the moment they purge their stores. - Delete all old content from those nodes but keep more recent content (but then only old files could be taken down while communication would continue) - Have nodes with a very small store positioned around the keyspace and move-swap all others into a very narrow portion of the keyspace. This can degrade performance, but if the stores are too small, lifetime will not be guaranteed, so some nodes will detect the attack and fill the space. - Blackhole all requests from a certain part of the keyspace to get nodes to leave that part. If the rate of pitch-black detection requests are much lower than the rate of swapping, the nodes will snap back with further swapping requests, because their peers will still be optimal for that part of the keyspace, or others will fill the void. With this change attackers can still degrade the service, but no longer disrupt it. If people run keepalive for important files, then most of the important but infrequently accessed content would be in caches and not only at the target nodes, so it could be reconstructed and would get re-inserted shortly after attackers purge their stores. Keepalive will be an official plugin starting with 1487. Frequently accessed content will already be in caches even if people don’t use keepalive for it. Question -------- Do you see powerful attacks on the new scheme that I missed? The next steps -------------- If no crippling weaknesses are found, I intend to implement this scheme during the following months. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
signature.asc
Description: PGP signature
