prop224: Fake client auth lines do not actually provide obfuscation
prop224 spec says:
If client auth is disabled, fake data is placed in each of the fields below
to obfuscate whether client authorization is enabled.
and
If client authorization is disabled, the fields here can be populated with random
data of the right size (that's 8 bytes for 'client-id', 16 bytes for 'iv'
and 16 bytes for 'encrypted-cookie' all encoded with base64).
However, after second thinking, those fake client auth lines don't actually confuse the adversaries we care about:
a) HSDir adversary with no onion address: This adversary does not learn whether client auth is enabled because of the desc padding anyway.
b) HSDir adversary with onion address: This adversary can decrypt the first desc layer, and then attempt to decrypt the second layer with no client auth info. If second layer decrypts, there is no client auth. If decryption fails, client auth is enabled.
Hence for both adversaries (a) and (b), the fact that we add fake client auth lines does not matter. Perhaps we could rip that feature out (get_fake_auth_client_str()
etc.)
The annoying thing here is that currently we actually require client auth lines since: T1N(str_desc_auth_client, R3_DESC_AUTH_CLIENT, GE(3), NO_OBJ)
.
As a first step here it might be a good idea to change the T1N()
to T0N()
and make sure that everything run ssmoothly when no client auth lines are provided.