I'm not sure I understand what you mean by brute-forcing in this case since I would not suggest any deterministic algorithm (like a hash) that takes an ASname and a timestamp and produces a string but just a AS number -> random id mapping, stored for a day or an hour and deleted after that.
Another way an attacker could take advantage of this: unique AS sign-up rate patterns "everyday there are about x new bridges in AS y" so it doesn't help much if we change the random AS id daily.
If an adversary submits a bridge descriptor from every (popular) AS (in every hour of) every day, they know which AS each bridge is from.
Understood, that is what I meant with:
Note: This introduces a confirmation opportunity, where attackers can learn the AS in which a new bridge is added if they added a bridge in the same AS on the same day. To reduce this problem it could be a hourly generated identifier.
Or, alternately, if they submit a bridge descriptor from an AS they are watching, then they know all the bridges in that AS.
And they don't actually need to be in the AS to submit a descriptor with an IP address from that AS.
Ok that makes it bad to a point where it is pointless. I'm surprised that you can get bridge auth to distribute fake bridges for arbitrary IPs - I assume that is not actually the case.
Anyway as I said, no need to pursue this any further, but thanks for the explaination.