Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hashes for blacklist should be salted #109

Open
moba opened this issue Aug 16, 2013 · 5 comments
Open

hashes for blacklist should be salted #109

moba opened this issue Aug 16, 2013 · 5 comments

Comments

@moba
Copy link

moba commented Aug 16, 2013

The hashes for the blacklist should be salted. The salt should be an option usually populated on installation.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/14806735-hashes-for-blacklist-should-be-salted?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).
@fpietrosanti
Copy link
Contributor

Will it prevent use of #25 ?

@moba
Copy link
Author

moba commented Aug 16, 2013

I don't want to share a blacklist with unknown entities. For #25, what you need to do is configure the same salt.

The way it is done now is more or less pointless, since it is definitely manageable to (pre)calculate all hashes and do a rainbow table lookup (for the .onions, not the partial blocks).

Personally, I don't want to take hash values from anyone else where I don't even know how they came to the conclusion to block it. If I use the method described in #25, then only to share the blacklist across multiple servers under our control. In the end, I'd rather generate the hash per system than share it.

@fpietrosanti
Copy link
Contributor

The #25 is a research topic, that will be required in the future with the network growing. The remote blacklist sharing could be based on consensus between different nodes (es: I partially trust nodes A, B, C, D, E, F and i automatically apply blocklist only to the hash that are available on all that nodes).

However yes, a salt is useful, but it should be something that can be used only for standalone nodes with no blocklist sharing (that now does not exists! :P)

@evilaliv3
Copy link
Contributor

i don't really understand the necessity of a salted hash. what is the use case?

it the reason is to avoid the possibility to find the blocklist of a tor2web node after a takedown i think that the salt does no add any additional protection.

if fact, given that the hidden servise naming space is huge, to bruteforce the list you need a list of known hs; in this case having a salt does not protect so much.

the only protection it gives is if the attacker want a list of know hs ad so make a bruteforce attack on the blocklist.

in addition adding a salt, as @fpietrosanti said, deny (makes more difficult) the possibility to implement a consensus rule by sharing lists.

@lotarso
Copy link

lotarso commented Mar 31, 2014

The administrator may provide the salt at the start up. So the salt is not stored on the system to protect the blacklist ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants