[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: questions about hidden service hashes, and experiences running hidden servic



hi,

A couple of points. First, unless I've fallen behind, SHA1 is only
broken to the point where you can generate two different arbitrary
datum and have them result to the same hash. This is not the same as
being able to "undo" SHA, or to even determine an arbitary collision
to a fixed hash. Unless I've missed something.

Second, even if this were the case, the hidden service is supposedly
only listed with the introduction points that the service connected to
through Tor. Assuming Tor remains unbroken, these Intro Points cannot
reveal the hidden service IP, and the public key of the hidden service
is not secret information anyway.

ah yes, i realised this after posting this question...

Here are some slides that illustrate the process of connecting to a
hidden service: http://www.freehaven.net/~arma/wth3.pdf

The one thing I would advise against is running your hidden service on
the same IP as your Tor server (or at least do not announce this
fact). This can leave you vulnerable to an intersection attack, where
the attacker keeps track of uptime of your hidden service and compares
it to uptime stats of the various tor servers. You only have 300-some
nodes to hide among.

connecting hidden services to tor servers is definitely verboten... i realised this straight away, what's the point of being able to hide where you are serving from if you then proceed to reveal it???


Incidentally, I would like to know exactly which directory server listing
hidden services are published in. I don't see any of them in
http://belegost.seul.org/ for example..

they aren't listed anywhere...

i'm glad to hear all these vague concerns dealt with. incidentally being able to generate the same hash from different data is not really a security issue, nor is it particularly onerous, except perhaps in the case of the unlikely event of collisions of hidden service hashes and with file hashes.

but the fact that collisions can occur should be a motivating reason behind finding a more hardened hash function to use. while there is no major issues right now, tor is unlikely to stop growing in node count, the more nodes, the proportionally greater chance of hash collisions. perhaps, at the very least, some kind of checking algorithm could be implemented to ensure that a generated hidden service public key does not collide with any other existent and online server would be a good idea.

kudos to the tor dev folks, tor rules! who needs freenet when when you can use tor? imo, redundancy should be the responsibility of the host, not the network.


loki

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! http://search.msn.com/