[cryptography] Potential funding for crypto-related projects

str4d str4d at i2pmail.org
Thu Jul 4 19:35:00 EDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Disclaimer: I'm an I2P developer, and a user of both Tor and I2P.

On 05/07/13 04:44, Michael Rogers wrote:
> As far as I can see, the attacks work by seizing control of the
> netDB, which is i2p's decentralised directory service.
> 
> "We first show how an attacker can tamper with the group of nodes 
> providing the netDB, until he controls most of these nodes."

Seizing (localized) control of the netDB relies on the default
automatic nature of floodfill participation, and the (then-valid)
assumption that by DoSing a legitimate floodfill to the point that it
drops its floodfill status, the attacker can "replace" it. The
hard-coded limit on the number of floodfills enabled this.

"Alternatively, the hard-coded number of active floodfill nodes could be
removed completely, and the count of floodfill nodes could be solely
regulated by the suitability metric, which would also prevent an
attacker from permanently removing legitimate nodes. After discussing
the issues with I2P developers, they confirmed that this is the
direction I2P is taking."

As the paper states (above), we are already moving in this direction -
floodfill numbers have not been limited since 0.9.5 and the bandwidth
requirements for becoming floodfill will be lowered in the next
release to include the top two tiers (possibly doubling the number of
floodfills).

[Apologies if this next part is straying off-topic for the list, but
to clarify the status-quo:]

Control of the netDB is just a stepping-stone. The actual
deanonymization step relies on a probabilistic link between the
storage of RouterInfos (which define a specific I2P user/router) and
the lookup of LeaseSets (which define a specific I2P
service/Destination). This stems from two issues:
- - RIs are stored via a direct connection to a floodfill, but
verification that the floodfill has stored it in "close" floodfills is
done via a connection from an exploratory tunnel outbound endpoint,
thus probabilistically linking a particular expl. tunnel's OBEP to an
I2P user.
- - LSs are looked up regularly (about every 10 minutes) through the
same pool of exploratory tunnels that RI verification is done through,
probabilistically linking service lookups from a particular OBEP to an
I2P user (via the first issue).

We are investigating possible solutions to sever this link, with
current suggestions being to either verify RI storage via direct
connections or to maintain two pools of exploratory tunnels (for
separate interaction with RIs and LSs in the netDB). If any list
members have suggestions on this front, I'm all ears :)

> To mount a similar attack against Tor, the attacker would have to 
> compromise the directory authorities that sign the network
> consensus. As far as we know that hasn't been done, so i2p's
> decision to use a decentralised netDB instead of centralised
> directory authorities has the practical effect of making these
> attacks possible.

I agree that the distributed netDB makes localized attacks easier
(though hopefully as above this risk is being reduced). I would argue
however that Tor having a small set of hard-coded directory
authorities means that a sufficiently-motivated attacker can
concentrate their resources and perform more widely-affecting attacks
than are possible with the ever-increasing network of floodfills.

> I agree that we should always keep in mind that there are 
> vulnerabilities we don't know about. However, we still have to
> make day-to-day decisions about which systems to use based on the 
> vulnerabilities we do know about.

Agreed. And like Tor and other projects, we are working on I2P's
vulnerabilities as we learn about them. As with any anonymity
technology, it's up to the user to decide what trade-offs they are
prepared to make, ideally based on the most current information available.

str4d
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCgAGBQJR1gaOAAoJENXeOJaUpGWyWZsIAIt0peQtW8PBABMwv5Wp6bNs
w4EsbxsharO5ffJffHYY2yMJHt5gLl3jCNDQrArR9ClGHSA4HwZlaAejrPo4mgiP
WRUGkYIbRGWJ6caXkifYNO+zJwZhiHuIAp2w2ONh9j9SarCv7MGrcdTtdxAF9EpB
P2jpvZ7SqQtiSiRqQ1Qw1kKKACtdQl4hNw89ImHT91lg3qiphK8og7u22OFRsdKm
DfvbvK9qaeIHv2y6bcF5x8+xSrg88jWHZBEX2kjr0LqOvQHtiXHK1ArACzJsR8gL
XSgbmLXCPKdiRba9KOQ1XZxcBBVuVbT7EX2DiKody6zHnt5qYZuYU+eVkSsexK0=
=WbDV
-----END PGP SIGNATURE-----


More information about the cryptography mailing list