Secure and privacy preserving DHT

[gpestana]

Good job with Hyperswarm! 👏 👏

I reckon there are no mechanisms in place in the DHT for protecting peers against passive and active attacks that could a) easily reveal the intentions of lookup initiators by leaking DHT requests and routing requests and b) allow active attackers to perform many different routing attacks, effectively serving poisonous content to lookup initiators.

Is the Hyperswam DHT somehow taking these potential vulnerabilities into consideration? If not, are there any plans to address these issues at any point? I'd be glad to discuss and help, if the topic is relevant for Hyperswarm.

[aral]

I’m sure that one of the authors can have a more definitive answer for you but, from what I understand, hyperswarm/the DHT doesn’t necessarily prevent this but the way that DAT does discovery (by using a cryptographically-secure hash of the public key to derive the discovery key) meliorates those concerns (definitely Concern B) by making it practically impossible to go from having the discovery key to obtaining the public key and thus getting read access to the DAT being advertised. So a routing attack should fail the moment the public key fails to verify and this should also mean that you cannot serve poisonous content to lookup initiators that are using the DHT with DAT.

If revealing the parties interested in the same topic is part of Concern A then, afaik, hyperswarm does not – and probably cannot – address that issue (anonymity).

Again, I’m not one of the authors so this is just a best-effort articulation of my understanding as someone using the modules and I’d appreciate corrections if I’m imprecise or incorrect in any way.

[pfrazee]

@aral that's accurate. @gpestana We're interested in solutions to preserve anonymity in the DHT. Our current implementation priority is reliability, but we're interested in privacy solutions if the tradeoffs can meet our requirements.