Re: Encrypting content of hidden service descriptors

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> Great to see your project starting up!

Thanks! :)

> First, I think you have gotten the first paragraph the wrong way. The
> key is simply a hash of the .onion address (but combined with cookies,
> time stamps and more [1]). The .onion address is the only known
> parameter to the hidden service's users and thus can be verified later
> when the public key is to be confirmed. The .onion address is not even
> known to the directory server.

Maybe I described another version than that in your paper. The features
you mention and describe in your paper (cookies, time stamps) improve
the security properties of hidden services, which start at the
descriptors, as you say.

However, the generation of the onion address is another issue than
encryption of the descriptor. So, I would rather postpone these (good!)
ideas to a later discussion when we talk about authentication of hidden
services. It simply would require too much work at the moment.

> The problem you are describing is mentioned in the paper, and is related
> to "the storage problem". Meaning that there is no easy way to let
> anyone store an encrypted (secret) string without letting others store
> nonsense (or whatever they want). Our proposed update scheme uses a
> reverse hash chain, and as you point out, neglected updates are a
> problem if the directory server allows non-updated entries to time out
> in a short amount of time (within a long? stop of service availability).
> This vulnerability can be reduced by allowing longer storage of
> descriptors, and the included added storage problems...
> 
> You are describing a problem that has its own limitations though. If the
> service really is to be hidden from everyone except the users as shown
> in the paper, then you have already lost if someone attacks the
> descriptor. Because the .onion address is supposed to be known only to
> the (honest) users of the service. If the users are bad we propose a way
> to distribute new .onion addresses which could be a way to go for the
> timeout problem as well.
> 
> But the storage problem is still real, [...]

You are right, the problem is still real and unsolved.

The reason why I asked the question is, that I am rethinking the format
of rendezvous service descriptors at the moment. And there still is this
idea around of encrypting the descriptor content which is, as you wrote,
not completely solved.

The question is, though, whether we need to solve it now. When
distributing the directory for hidden service descriptors, everyone
could be responsible for storing a descriptor and could read it, if it
is unencrypted. At the moment you as hidden service provider need to
trust only the five directory authorities, in a decentralized design you
further need to trust each of the 500 DHT nodes...

> [...] and might be addressed by using
> puzzles [...]

That means you want to require a puzzle for every publish operation,
maybe with increasing complexity, and store all received descriptors?
This would make an attack on service availability of a hidden service
more expensive. But if some three-letter agency wanted to block a hidden
service, they probably wouldn't care. I don't think that puzzles are an
effective solution.

> [...] or other schemes to allow for long term storage in the DHT/DS?

Then you would store a long-term entry as basis for the reverse hash
scheme that you mention in your paper and allow only one current
descriptor? I think it's not too safe to rely on long-term availability
of DHT entries. That's not what they were built for, because it would
require very much replication to never, never loose an entry. And if we
did this in a centralized fashion, the merits of the decentralization
were lost. Maybe long-term storage is too expensive to be a good solution.

> I have no answer to this (now:), but maybe someone else has?

I don't see such a solution at the moment, either. :(

> Hope this answers some of your initial concerns even if the most
> important one is still open.

At least your reply confirms my doubts to simply encrypt descriptors and
hope the best. :)

Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGIRbx0M+WPffBEmURArfTAKCOy9bM6BHhyw7IjC76Nmu12hJ9AACfZG5d
ONf3c2soNdgfHbf3m/X1dMo=
=AFnZ
-----END PGP SIGNATURE-----