[or-cvs] r16303: Proposal 121: Limit maximum descriptor size to 20 kilobytes (tor/trunk/doc/spec/proposals)
kloesing at seul.org
kloesing at seul.org
Thu Jul 31 13:27:14 UTC 2008
Author: kloesing
Date: 2008-07-31 09:27:14 -0400 (Thu, 31 Jul 2008)
New Revision: 16303
Modified:
tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
Log:
Proposal 121: Limit maximum descriptor size to 20 kilobytes to prevent abuse.
Modified: tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt
===================================================================
--- tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2008-07-31 12:18:14 UTC (rev 16302)
+++ tor/trunk/doc/spec/proposals/121-hidden-service-authentication.txt 2008-07-31 13:27:14 UTC (rev 16303)
@@ -26,6 +26,8 @@
scalable authorization protocol (2.2), rewrote existing
authorization protocol (2.3); changes based on discussion
with Nick
+ 31-Jul-2008 Limit maximum descriptor size to 20 kilobytes to prevent
+ abuse.
Overview:
@@ -212,6 +214,23 @@
(clients and servers would have to be upgraded anyway for using the new
features).
+ An adversary could try to abuse the fact that introduction points can be
+ encrypted by storing arbitrary, unrelated data in the hidden service
+ directory. This abuse can be limited by setting a hard descriptor size
+ limit, forcing the adversary to split data into multiple chunks. There
+ are some limitations that make splitting data across multiple descriptors
+ unattractive: 1) The adversary would not be able to choose descriptor IDs
+ freely and have to implement an own indexing structure. 2) Validity of
+ descriptors is limited to at most 24 hours after which descriptors need
+ to be republished.
+
+ The regular descriptor size in bytes is 745 + num_ipos * 837 + auth_data.
+ A large descriptor with 7 introduction points and 5 kilobytes of
+ authorization data would be 11724 bytes in size. The upper size limit of
+ descriptors should be set to 20 kilobytes, which limits the effect of
+ abuse while retaining enough flexibility in designing authorization
+ protocols.
+
1.2. Client authorization at introduction point
The next possible authorization point after downloading and decrypting
More information about the tor-commits
mailing list