Additions:
===Request Level: If you are already connected to the target===
On Freenet 0.5, correlation attacks were possible. On Freenet 0.7, they are still possible, but they may be somewhat easier because routing works on 0.7 (and because of how it works). Note that these attacks require the attacker to be close to the target already.
One possible solution is PremixRouting - a layer of onion routing before the request starts. This has now been largely abandoned in favour of random routed encrypted tunnels, or in the shorter term routing bundles of requests together. The problem with premix routing is that it takes a huge number of hops on a darknet to gain a reasonable anonymity set: The real threat is not direct peers, it's [[KeySearchAttack tracing from a distance]] (adaptive search), and making it look like you are part of a small cluster of nodes really doesn't help much!
Of course, you have to get a connection to the target in order to do this. On a small opennet (the current situation, sadly), this is easy: create an ubernode, make it pretend to be very many nodes, harvest the network, connect to every known node. On 0.7 darknet this is supposed to be very hard - especially if you don't know who the target is, which is the usual situation. Obviously stupid users will cause security problems by connecting to well known ubernodes which might be run by evildoers.
The objective of both of these mechanisms is to investigate the topology of the network in order to improve performance, diagnose problems etc. They will be removed before 1.0, and hopefully sooner. However, much similar information can be obtained on darknet from swapping.
The Frost message boards system is not part of Freenet proper, however very many Freenet users use it, and it is *seriously* vulnerable to spam as has recently demonstrated. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. Another chat system, FMS, does not have this problem, but is written in C''''+''''+ and therefore cannot be bundled with the node or integrated into Frost. A third chat system, Freetalk, is under development and will be integrated into the node. Both FMS and Freetalk support "negative trust", meaning that once a newbie announces (via captchas), he can be silenced by a few people saying he is a spammer. This has provoked many flamewars, and alternatives have been discussed and may be implemented; it is a tradeoff between more spam (by everyone seeing newbies and making their own mind up e.g.) and more "community censorship" (by newbies being easily blocked because they might be spammers).
On Freenet 0.5, correlation attacks were possible. On Freenet 0.7, they are still possible, but they may be somewhat easier because routing works on 0.7 (and because of how it works). Note that these attacks require the attacker to be close to the target already.
One possible solution is PremixRouting - a layer of onion routing before the request starts. This has now been largely abandoned in favour of random routed encrypted tunnels, or in the shorter term routing bundles of requests together. The problem with premix routing is that it takes a huge number of hops on a darknet to gain a reasonable anonymity set: The real threat is not direct peers, it's [[KeySearchAttack tracing from a distance]] (adaptive search), and making it look like you are part of a small cluster of nodes really doesn't help much!
Of course, you have to get a connection to the target in order to do this. On a small opennet (the current situation, sadly), this is easy: create an ubernode, make it pretend to be very many nodes, harvest the network, connect to every known node. On 0.7 darknet this is supposed to be very hard - especially if you don't know who the target is, which is the usual situation. Obviously stupid users will cause security problems by connecting to well known ubernodes which might be run by evildoers.
The objective of both of these mechanisms is to investigate the topology of the network in order to improve performance, diagnose problems etc. They will be removed before 1.0, and hopefully sooner. However, much similar information can be obtained on darknet from swapping.
The Frost message boards system is not part of Freenet proper, however very many Freenet users use it, and it is *seriously* vulnerable to spam as has recently demonstrated. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. Another chat system, FMS, does not have this problem, but is written in C''''+''''+ and therefore cannot be bundled with the node or integrated into Frost. A third chat system, Freetalk, is under development and will be integrated into the node. Both FMS and Freetalk support "negative trust", meaning that once a newbie announces (via captchas), he can be silenced by a few people saying he is a spammer. This has provoked many flamewars, and alternatives have been discussed and may be implemented; it is a tradeoff between more spam (by everyone seeing newbies and making their own mind up e.g.) and more "community censorship" (by newbies being easily blocked because they might be spammers).
Deletions:
On Freenet 0.5, correlation attacks were possible. On Freenet 0.7, they are still possible, but they may be somewhat easier because routing works on 0.7 (and because of how it works).
The long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
Of course, you have to get a connection to the target in order to do this. On 0.5, or on opennet, this is easy: create an ubernode, make it pretend to be very many nodes, harvest the network, connect to every known node. On 0.7 darknet this is supposed to be very hard - especially if you don't know who the target is, which is the usual situation. Obviously stupid users will cause security problems by connecting to well known ubernodes which might be run by evildoers.
The objective of both of these mechanisms is to investigate the topology of the network and determine whether it is unreasonable as a result of not having opennet, or whether there is a problem with swapping etc.
The Frost message boards system is not part of Freenet proper, however very many Freenet users use it, and it is *seriously* vulnerable to spam as has recently demonstrated. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. A new chat system, FMS, is under development, but at the moment is written in C''''+''''+ and therefore cannot be bundled with the node or integrated into Frost, and has a poor user interface.
Additions:
At present there is some random size padding and message coalescing. However, we are probably still fairly vulnerable to traffic analysis against a powerful attacker because we have to send very small packets frequently to keep the search latency low, while we send larger packets only when transferring data. Hopefully individual data transfers cannot be reliably traced across busy nodes.
As regards invisibility: We have no fixed session bytes (unlike 0.5), even on connection setup (because of the outer encryption layer). However our profile may be detectable based on packet size and the fact that the connection is UDP. It may help later on to support variable data packet sizes within bulk transfers and block transfers. Traffic flow analysis will identify Freenet traffic, if the attacker has the hardware. Data flows can also be observed to some degree, on any relayed protocol; traversing busy nodes helps, but may not help enough. The only real solution to that is constant bit rate links, or approximations to that (e.g. [[HardStego stego transports]] which determine the data rate without reference to the amount of data to transfer).
In July 2009, [[http://www.schneier.com/blog/archives/2009/07/another_new_aes.html Bruce Schneier]] discussed a related-key attack on AES. This attack is stronger against 256-bit key AES than 128-bit key AES. Its applicability to 256-bit block size AES is not discussed. In practice, a related-key attack against AES would be very hard to implement, provided that the key selection scheme and random number generator are secure. See also the [[http://archives.freenetproject.org/message/20090731.180715.a5767631.en.html discussion on the devl list]]. More recently, more weaknesses in AES key setup with 256-bit keys have been discovered; we may add more rounds to avoid this, as discussed in Schneier's blog.
As regards invisibility: We have no fixed session bytes (unlike 0.5), even on connection setup (because of the outer encryption layer). However our profile may be detectable based on packet size and the fact that the connection is UDP. It may help later on to support variable data packet sizes within bulk transfers and block transfers. Traffic flow analysis will identify Freenet traffic, if the attacker has the hardware. Data flows can also be observed to some degree, on any relayed protocol; traversing busy nodes helps, but may not help enough. The only real solution to that is constant bit rate links, or approximations to that (e.g. [[HardStego stego transports]] which determine the data rate without reference to the amount of data to transfer).
In July 2009, [[http://www.schneier.com/blog/archives/2009/07/another_new_aes.html Bruce Schneier]] discussed a related-key attack on AES. This attack is stronger against 256-bit key AES than 128-bit key AES. Its applicability to 256-bit block size AES is not discussed. In practice, a related-key attack against AES would be very hard to implement, provided that the key selection scheme and random number generator are secure. See also the [[http://archives.freenetproject.org/message/20090731.180715.a5767631.en.html discussion on the devl list]]. More recently, more weaknesses in AES key setup with 256-bit keys have been discovered; we may add more rounds to avoid this, as discussed in Schneier's blog.
Deletions:
As regards invisibility: We have no fixed session bytes (unlike 0.5), even on connection setup (because of the outer encryption layer). However our profile may be detectable based on packet size and the fact that the connection is UDP. It may help later on to support variable data packet sizes within bulk transfers and block transfers.
In July 2009, [[http://www.schneier.com/blog/archives/2009/07/another_new_aes.html Bruce Schneier]] discussed a related-key attack on AES. This attack is stronger against 256-bit key AES than 128-bit key AES. Its applicability to 256-bit block size AES is not discussed. In practice, a related-key attack against AES would be very hard to implement, provided that the key selection scheme and random number generator are secure. See also the [[http://archives.freenetproject.org/message/20090731.180715.a5767631.en.html discussion on the devl list]].
Revision [3511]
Edited on 2009-11-12 12:20:09 by MatthewToseland [update datastore, mention that the trail may exist for caches]Additions:
On Freenet 0.5, everything you requested or inserted had a good chance of being stored in your datastore, especially if it wasn't full. This means that if an attacker managed to seize your store, they could identify what you had been browsing - at least in terms of large splitfiles. On 0.7, as of build 1224, we don't store anything locally requester or inserted, or requested or inserted by nearby nodes: We cache after HTL drops to 16 on requests, and 15 on inserts (it starts at 18 but has a 50% chance of staying at 18 on each hop). We do however cache local and nearby requests in our "client cache", which isn't used by the network but only by the client layer, and can be encrypted or automatically wiped on restart, and we have a short-term "slashdot cache". It may be possible to trace an insert across the network by probing datastores, to the point of being a few hops away from the target and thus perhaps being able to guess it by other attacks, but this relies on data still being in caches (they have very limited lifetime in most cases), timing or overload attacks (or costly bloom filter transfers) to determine whether something is in the datastore, etc; it's a very expensive attack, the adaptive search is much faster and more efficient, but requires intercepting the data while it is being inserted (or requested). Encrypted tunnels hopefully will solve both problems, but will be expensive. Bundle routing would solve this problem and partly help with adaptive search; we have some options.
Deletions:
1. Store nothing: Local requests/inserts are not cached in the datastore. The advantage is that if your store is seized, it won't give away much information. The disadvantage is that if your darknet peers are evil they can probe your store after an insert to determine whether your request is local.
2. Store everything: Local requests/inserts are cached in the datastore. You are safe from your darknet peers probing after seeing a request, but if your store is seized it will incriminate you.
Additions:
A correlation attack essentially is of the form "Peer A is doing a group of requests. I recognize that the splitfile he is fetching is X, and that he is fetching exactly 25% of it from me (and I know he has four peers). Therefore, it is probably a local request for that splitfile". This can also be helped by knowing the HTL, and another approach is to look at the closeness of the key to the specialization of the node the requests are being sent to. Essentially it's a statistical attack. The first form relies on the attacker knowing the splitfile; key closeness on the other hand may not have this requirement.
The long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
The long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
Deletions:
Based on the [[http://www.besttermpaper.com research paper]] whe've written, the long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
Additions:
A correlation attack on [[http://www.besttermpaper.com term papers]] essentially is of the form "Peer A is doing a group of requests. I recognize that the splitfile he is fetching is X, and that he is fetching exactly 25% of it from me (and I know he has four peers). Therefore, it is probably a local request for that splitfile". This can also be helped by knowing the HTL, and another approach is to look at the closeness of the key to the specialization of the node the requests are being sent to. Essentially it's a statistical attack. The first form relies on the attacker knowing the splitfile; key closeness on the other hand may not have this requirement.
Based on the [[http://www.besttermpaper.com research paper]] whe've written, the long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
Based on the [[http://www.besttermpaper.com research paper]] whe've written, the long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
Deletions:
The long-term solution is PremixRouting - a layer of onion routing before the request starts. There may be other solutions which help to some degree, for example, fixed routes for large bundles of requests for the first few hops. PremixRouting will probably not be implemented until 0.8, as it appears very difficult either on a darknet or an opennet. It will probably require the network topology to be exposed, and some sort of cellular structure, so that a request has a defined anonymity set; it could have started on any node in the cell.
Additions:
Pozwala to systemowi dodać dodatkową warstwę. Publikujemy we freenecie pliki, które nie maja treści same w sobie. Są zaszyfrowane lub sa cześcią większego pliku. (Sam system szyfruje pliki CHK@), ale taki plik może leżeć jakis czas uśpiony. I po np. dobie, po losowej ilości godzin (4-17), gdy ktoś opublikuje notke na innym flogu czy napisze informacje we fros lub FMS pojawi się nowy plik. Mając jego nazwę odszyfrowujemy go. Bez znania nazwy pełnej nie jestesmy w stanie go zablokować. A gdy bedziemy juz znac nazwe nie ma jak go zablokować bo krąży juz np. od 3 dni po freenecie. Takie ujawnienie się czy wykonanie skryptu można wysłac do kilku węzłów. Nie ma to znaczenia gdyz jesli zrobimy plik o dokladnie takich samych parametrach (nazwie, skrócie, zawartości) to nie trzeba bedzie go publikowac bo freenet nie wyona po prostu tego. W ten sposób anonimowośc będzie idealna. Niezalezna od predkości przesyłania siecią czegokolwiek.
Google translation of the above:
The idea is simple and somewhat similar to software git / svn. The point is that you can publish the files, which would check whether a new version (that is, our poczciwe ChK @) The only difference was that in that it does not podawalibyśmy the entire file, but only the difference. Another version in our repository.
Another idea may be more important are the so-called trigery. Note that the node, and so has to check whether there is a new version of the file ChK @. This could be a little rozszeżyć brought something to the shape of language scripts. But it would be very limited. As for the programming language specific shader graphics or other operations that do not have the command "if" there could be assumed that the script file zmiesciłby in 2KiB and does not contain a loop, and the same conditions.
For example, if we are to publish the contents of a large we can not disguise the fact that the transmission of data. Different ways to help reduce bandwidth dodatowo hub and show you how communication. The very few randomized uploader change in this situation. But by adding this condition. If there is one week after the publication of the deposits of the two files and make it one. Or, if you will get a file that contains the word "something" publish file on the network to password odszyfrowujac such and such.
This allows the system to add an additional layer. We publish in freenecie files that have no content in their own right. They are encrypted or are part of a larger file. (The system encrypts files ChK @), but such a file may be asleep from time to time. I, for example, after an era, after a random time (4-17) when you publish a notice on another flogu or write information in FMS fros or a new file. Taking its name odszyfrowujemy it. Without well-known names are not fully able to block it. And when we already know the name does not block it as it already is circulating for example, from 3 days after freenecie. Such disclosure is whether the execution of the script you can send to multiple nodes. Not because it is irrelevant if you do file with exactly the same parameters (name, summary, content) does not need to publish it because wyona freenet not just that. In this way, anonymity will be perfect. Independent from the speed of the transmission network anything.
Google translation of the above:
The idea is simple and somewhat similar to software git / svn. The point is that you can publish the files, which would check whether a new version (that is, our poczciwe ChK @) The only difference was that in that it does not podawalibyśmy the entire file, but only the difference. Another version in our repository.
Another idea may be more important are the so-called trigery. Note that the node, and so has to check whether there is a new version of the file ChK @. This could be a little rozszeżyć brought something to the shape of language scripts. But it would be very limited. As for the programming language specific shader graphics or other operations that do not have the command "if" there could be assumed that the script file zmiesciłby in 2KiB and does not contain a loop, and the same conditions.
For example, if we are to publish the contents of a large we can not disguise the fact that the transmission of data. Different ways to help reduce bandwidth dodatowo hub and show you how communication. The very few randomized uploader change in this situation. But by adding this condition. If there is one week after the publication of the deposits of the two files and make it one. Or, if you will get a file that contains the word "something" publish file on the network to password odszyfrowujac such and such.
This allows the system to add an additional layer. We publish in freenecie files that have no content in their own right. They are encrypted or are part of a larger file. (The system encrypts files ChK @), but such a file may be asleep from time to time. I, for example, after an era, after a random time (4-17) when you publish a notice on another flogu or write information in FMS fros or a new file. Taking its name odszyfrowujemy it. Without well-known names are not fully able to block it. And when we already know the name does not block it as it already is circulating for example, from 3 days after freenecie. Such disclosure is whether the execution of the script you can send to multiple nodes. Not because it is irrelevant if you do file with exactly the same parameters (name, summary, content) does not need to publish it because wyona freenet not just that. In this way, anonymity will be perfect. Independent from the speed of the transmission network anything.
Deletions:
Additions:
In July 2009, [[http://www.schneier.com/blog/archives/2009/07/another_new_aes.html Bruce Schneier]] discussed a related-key attack on AES. This attack is stronger against 256-bit key AES than 128-bit key AES. Its applicability to 256-bit block size AES is not discussed. In practice, a related-key attack against AES would be very hard to implement, provided that the key selection scheme and random number generator are secure. See also the [[http://archives.freenetproject.org/message/20090731.180715.a5767631.en.html discussion on the devl list]].
Additions:
===Better nodes ===
Two ideas to better freenet nodes in Polish
Idea jest prosta i trochę podobna do oprogramowania git/svn. Chodzi o to by mozna było publikowac pliki, które by sprawdzały czy jest nowa wersja (czyli nasze poczciwe CHK@) Jedyna różnica była by w tym, że nie podawalibyśmy całego pliku, a jedynie różnicę. Kolejną wersję w naszym repozytorium.
Drugim może bardziej istotnym pomysłem sa tak zwane trigery. Zauważmy, że wezeł i tak musi sprawdzać czy nie pojawiła się nowa wersja pliku CHK@. Można by to troszkę rozszeżyć wprowadzajac cos na kształt jezyka skryptów. Ale byłby on bardzo ograniczony. Tak jak specyficzne języki do programowania shaderów czy innych operacji graficznych, które nie posiadaja poleceń "if" tu można by było założyć, że skrypt zmiesciłby się w pliku 2KiB i nie zawierał pętli, a same warunki.
przykładowo jeśli mamy opublikować dużą treść nie mamy możliwości ukrycia faktu przesyłania danych. Różne sposoby pozwalają dodatowo ograniczyć przepustowość węzła i pozwalaja zobaczyć jak przebiega komunikacja. Sama losowosć wysyłania plików niewiele zmienia w tej sytuacji. Ale wystarczy dodać taki warunek. Jeśli jest tydzień po opublikowaniu pliku złóż z dwóch plików i zrób z niego jeden. Albo jeśli pojawi sie plik zawierajacy słowo "coś" opublikuj plik w sieci odszyfrowujac go hasłem takim a takim.
Pozwala to systemowi dodać dodatkową warstwę. Publikujemy we freenecie pliki, które nie maja treści same w sobie. Są zaszyfrowane lub sa cześcią większego pliku. (Sam system szyfruje pliki CHK@), ale taki plik może leżeć jakis czas uśpiony. I po np. dobie, po losowej ilości godzin (4-17), gdy ktoś opublikuje notke na innym flogu czy napisze informacje we fros lub FMS pojawi się nowy plik. Mając jego nazwę odszyfrowujemy go. Bez znania nazwy pełnej nie jestesmy w stanie go zablokować. A gdy bedziemy juz znac nazwe nie ma jak go zablokować bo krąży juz np. od 3 dni po freenecie. Takie ujawnienie się czy wykonanie skryptu można wysłac do kilku węzłów. Nie ma to znaczenia gdyz jesli zrobimy plik o dokladnie takich samych parametrach (nazwie, skrócie, zawartości) to nie trzeba bedzie go publikowac bo freenet nie wyona po prostu tego. W ten sposób anonimowośc będzie idealna. Niezalezna od predkości przesyłania siecią czegokolwiek.
Two ideas to better freenet nodes in Polish
Idea jest prosta i trochę podobna do oprogramowania git/svn. Chodzi o to by mozna było publikowac pliki, które by sprawdzały czy jest nowa wersja (czyli nasze poczciwe CHK@) Jedyna różnica była by w tym, że nie podawalibyśmy całego pliku, a jedynie różnicę. Kolejną wersję w naszym repozytorium.
Drugim może bardziej istotnym pomysłem sa tak zwane trigery. Zauważmy, że wezeł i tak musi sprawdzać czy nie pojawiła się nowa wersja pliku CHK@. Można by to troszkę rozszeżyć wprowadzajac cos na kształt jezyka skryptów. Ale byłby on bardzo ograniczony. Tak jak specyficzne języki do programowania shaderów czy innych operacji graficznych, które nie posiadaja poleceń "if" tu można by było założyć, że skrypt zmiesciłby się w pliku 2KiB i nie zawierał pętli, a same warunki.
przykładowo jeśli mamy opublikować dużą treść nie mamy możliwości ukrycia faktu przesyłania danych. Różne sposoby pozwalają dodatowo ograniczyć przepustowość węzła i pozwalaja zobaczyć jak przebiega komunikacja. Sama losowosć wysyłania plików niewiele zmienia w tej sytuacji. Ale wystarczy dodać taki warunek. Jeśli jest tydzień po opublikowaniu pliku złóż z dwóch plików i zrób z niego jeden. Albo jeśli pojawi sie plik zawierajacy słowo "coś" opublikuj plik w sieci odszyfrowujac go hasłem takim a takim.
Pozwala to systemowi dodać dodatkową warstwę. Publikujemy we freenecie pliki, które nie maja treści same w sobie. Są zaszyfrowane lub sa cześcią większego pliku. (Sam system szyfruje pliki CHK@), ale taki plik może leżeć jakis czas uśpiony. I po np. dobie, po losowej ilości godzin (4-17), gdy ktoś opublikuje notke na innym flogu czy napisze informacje we fros lub FMS pojawi się nowy plik. Mając jego nazwę odszyfrowujemy go. Bez znania nazwy pełnej nie jestesmy w stanie go zablokować. A gdy bedziemy juz znac nazwe nie ma jak go zablokować bo krąży juz np. od 3 dni po freenecie. Takie ujawnienie się czy wykonanie skryptu można wysłac do kilku węzłów. Nie ma to znaczenia gdyz jesli zrobimy plik o dokladnie takich samych parametrach (nazwie, skrócie, zawartości) to nie trzeba bedzie go publikowac bo freenet nie wyona po prostu tego. W ten sposób anonimowośc będzie idealna. Niezalezna od predkości przesyłania siecią czegokolwiek.
Additions:
I am not sure exactly how we will secure the current LoadBalancing system; it does involve feedback going back to the originator of the requests which then changes its frequency of sending requests. Right now this means that it *may* be possible to tell which requests made by your direct peers are locally originated. Maybe premix routing will fix this... maybe not, in the presence of colluding nodes. It is likely that load balancing will undergo radical changes in the not too distant future. Apart from that, flooding the network with requests or inserts may be viable; it will hopefully be contained, but only by requests being rejected, not only those of the attacker but everyone else's too, and if he has multiple entry points via opennet, he can do some major mischief.
Deletions:
Additions:
A correlation attack essentially is of the form "Peer A is doing a group of requests. I recognize that the splitfile he is fetching is X, and that he is fetching exactly 25% of it from me (and I know he has four peers). Therefore, it is probably a local request for that splitfile". This can also be helped by knowing the HTL, and another approach is to look at the closeness of the key to the specialization of the node the requests are being sent to. Essentially it's a statistical attack. The first form relies on the attacker knowing the splitfile; key closeness on the other hand may not have this requirement.
Deletions:
Additions:
Many of the attacks described on the [[OpennetAttacks opennet attacks page]] may also work against darknets, albeit much more slowly. You can't harvest a darknet, but you can do an adaptive search the same as you would on opennet (the difference is each connection costs much more than it would have on opennet).
Additions:
The Frost message boards system is not part of Freenet proper, however very many Freenet users use it, and it is *seriously* vulnerable to spam as has recently demonstrated. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. A new chat system, FMS, is under development, but at the moment is written in C''''+''''+ and therefore cannot be bundled with the node or integrated into Frost, and has a poor user interface.
Deletions:
Additions:
The Frost message boards system is not part of Freenet proper, however very many Freenet users use it, and it is *seriously* vulnerable to spam as has recently demonstrated. At this point most boards are flooded with invisible spam, an effective DoS attack on any one-KSK-queue-per-board based chat system. A new chat system, FMS, is under development, but at the moment is written in C++ and therefore cannot be bundled with the node or integrated into Frost, and has a poor user interface.
Deletions:
Additions:
Cancer nodes could return DNF to every request. We have implemented a partial solution with FailureTables.
Deletions:
Additions:
We have also added a unique identifier to each location in the swap requests. This will enable us to reconstruct the long-range structure of the network by watching the swap requests which pass through our node. Obviously an attacker can do the same analysis. However for short-range topology, this can already be done reasonably accurately, and it's the short range that is really interesting to an attacker (we hope). This code is disabled at the moment.
Deletions:
Additions:
We have also added a unique identifier to each location in the swap requests. This will enable us to reconstruct the long-range structure of the network by watching the swap requests which pass through our node. Obviously an attacker can do the same analysis. However for short-range topology, this can already be done reasonably accurately, and it's the short range that is really interesting to an attacker (we hope). This mechanism is disabled at the moment.
Deletions:
Additions:
The location swapping algorithm as currently implemented is not secure. An attacker can damage the network through bogus swap requests. In fact, this happens naturally through nodes joining and leaving the network. So we have made the node randomly reset its location every few days. According to our math guru this should protect the network against natural degeneration. Whether it protects it against an active attack is another question. More info on attacking the swapping algorithm [[http://crisp.cs.du.edu/pitchblack/ here]].
We have some ideas on how to secure the swapping algorithm in 0.8 [[SwappingImprovements here]].
At the moment a large part of the topology is exposed through swapping: Because swap requests are routed randomly for 6 hops, there is no way of encrypting the exchange. Therefore any intermediate node can see the two nodes' locations and their peers' locations. It is likely that this will remain the case, and possibly even be expanded in order to try to secure the swapping process.
We have some ideas on how to secure the swapping algorithm in 0.8 [[SwappingImprovements here]].
At the moment a large part of the topology is exposed through swapping: Because swap requests are routed randomly for 6 hops, there is no way of encrypting the exchange. Therefore any intermediate node can see the two nodes' locations and their peers' locations. It is likely that this will remain the case, and possibly even be expanded in order to try to secure the swapping process.
Deletions:
Worse, there are indications that not only are attacks on the swapping algorithm both easy and effective, but that the network will degenerate by itself over time into a state of all node locations clustered into a few small parts of the keyspace due to join-leave churn! We are working on a solution to this problem as a matter of urgency, probably involving occasionally resetting nodes' locations.
At the moment a large part of the topology is exposed through swapping: Because swap requests are routed randomly for 6 hops, there is no way of encrypting the exchange. Therefore any intermediate node can see the two nodes' locations and their peers' locations.
Additions:
The location swapping algorithm as currently implemented is not secure. If the topology is explicitly exposed then swaps can be enforced. Exposing the topology to some degree is also required for premix routing, so this is the direction we will move towards in the long term. More [[http://crisp.cs.du.edu/pitchblack/ here]].
Deletions:
Additions:
From build 1066, we use [[http://wiki.freenetproject.org/JFki JFki]], a [[http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange Diffie-Hellman]] variant which supports pre-calculation of almost everything and is therefore highly resistant to denial of service attacks on both CPU and memory. This is partly thanks to a Summer of Code student. This is surrounded by an outer, symmetric encryption layer using both nodes' identities for invisibility. All Freenet 0.7 packets look like random data. Until late 2007, our DH code (in all versions of Freenet) was vulnerable to weak keys.
