Freenet 0.7 Security
From build 1066, we use JFki∞
, a 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.
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.
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.
Also, at the moment our encryption uses the hash of the plaintext as
the IV (after adding 12 bytes of random padding), and the same
encryption key in both directions. This probably isn't a good idea. See
. According to NIST∞
, the IV must be unpredictable for CFB mode, so this may be a weakness (we use PCFB∞
but our implementation is identical to CFB∞
because the key size and block size are identical).
Finally, we use Rijndael with 256-bit keys and 256-bit blocks. AES, the
form of Rijndael which was approved by FIPS and the NSA (including for
top secret documents), uses a 128-bit block size, because most
cryptanalysis involved in the standardisation process focused on that
block length. So theoretically there may be attacks on Rijndael with
256-bit block size that don't work with 128-bit block size. If you hear
of any, tell us!
Request Level: Darknet Peers
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).
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. 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.
In any case the bottom line is if you fetch, or insert, a large
splitfile, and your darknet peers (your supposedly trusted neighbours)
do some statistical attacks, they can identify that the request is
probably from you. This could be very bad!
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.
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, there will be the option to choose between two
policies (at present the second is fixed):
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.
Location Swapping and network topology
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 here∞
(the paper hasn't been published yet).
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.
Topology debugging/diagnostic tools
Probe requests: We provide a mechanism to send a request for the
closest node location greater than a specified value. We send a probe
request, this is routed normally, it returns the number of hops it
took, the closest location found that is greater than the target, and
the closest location found. At the moment this also returns hop by hop
information on the locations, peers, and unique identifiers (see below)
of the nodes the request passed through.
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
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
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
will not be constrained in any way by the current load balancing
Cancer nodes could return DNF to every request. We could maybe do something about this with FailureTables
deserves an attacks page
all of its own.
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. It is probably possible to radically
improve its security against spam, but this is currently in the early
design / discussion phase.
All in all, Freenet 0.7's security leaves much room for improvement,
but in many ways is probably an improvement on 0.5. On a true darknet,
whole classes of attacks are far more difficult and there is the
possibility of hiding the network and running it in hostile
environments where 0.5 may have been blocked very cheaply.
for information on actual attacks which we think have been carried out.