-----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----- _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
