Encrypting content of hidden service descriptors

[Karsten Loesing <karsten.loesing@xxxxxxx>]

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

There have been proposals around to encrypt the content of hidden
service descriptors, so that only authorized users can decrypt them. The
decryption key should have been given to authorized clients only. The
onion address could then be calculated as a secure hash of this key.

Two reasons were given to do this: (1) An adversary (including an
untrustworthy directory server) who does not know the decryption key
cannot determine the introduction points included in the descriptor and
thus not perform an attack on them. (2) An adversary (no directory
server) cannot derive the onion address and therefore cannot conclude a
hidden service's online activity.

I think that this was originally proposed by Øverlier and Syverson in
their Valet node paper and was written to the Tor homepage as a possible
extension.

I am not sure, but perhaps I have found a flaw in this scheme:

The encrypted descriptor looks like random data to someone without the
decryption key and thus cannot be validated by a directory server when
storing it. What if a hidden service is not available for some time and
does not renew a previously stored descriptor? Someone else could store
some non-sense data as descriptor for the hidden service of which she
knows the onion address. How can the directory deny storage of this
descriptor without validating its origin? If the hidden service wants to
store the real descriptor, how can the directory decide whether to
overwrite the old descriptor or not? If the directory stores all
descriptors, what prevents someone to store a million non-sense
descriptors before the real hidden service stores the real descriptor?

On the other hand, if encryption is combined with a signature that
everyone can verify, this discloses the hidden service's online activity
to the public, doesn't it? This would break reason (2) mentioned above.

What do you think? Did I miss some important point?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGH+Xz0M+WPffBEmURAkevAJ92R1GaqIndou63m3eVh1HyixgKCwCdGtDS
NyM6h3iv9/OHBoQI6ckGLZI=
=v1UP
-----END PGP SIGNATURE-----