[Noisebridge-discuss] a noisebridge API question, or oracles a-go-go

[Seth David Schoen]

Danny O'Brien writes:

> Josh pointed out some problems with this -- firstly you could create
> lots of keys really quickly, and secondly you could use it as an
> oracle to find out existing valid keys.
> 
> The obvious solution to both of these issues is rate-limiting, but I'm
> having problems working out good ways to do this that actually solve
> the problem. For instance, I could rate-limit so that after a bunch of
> non-valid door codes, everyone gets locked out for a few minutes, but
> that would enable to people to just block other people from using it
> (probably not a big deal). I could also rate-limit so that a
> particular key can't get more than a certain number of daughter keys,
> but then you could just call again using a daughter key and reset that
> counter.

For the oracle problem, you could do something to make such a query
computationally expensive: requiring hashcash or requiring the query
to be accompanied by a valid scrypt of the parent door code plus a
Noisebridge door-specific salt value.  (I think the latter solution
has some troubles because natural implementations may lead either to
a denial of service possibility -- if the scrypt values are always
verified in real-time -- or a timing oracle -- if the scrypt values
are verified only when the door code presented is valid.  Both of
these problems can probably be avoided by storing the legitimate
scrypt value together with the door code itself when the door code
is originally created.)  Both of these solutions do have the problem
that someone with access to a botnet can still enumerate valid codes
by brute force, although you could have an absolute limit on the
number of "valid" queries per day (I think only in the hashcash case,
not the scrypt case).

For the daughter-code problem, it seems straightforward to allow door
codes to accumulate "invitations" at a fixed rate, representing the
balance of the number of daughter codes that can be generated from an
existing code within a particular period of time.

-- 
Seth David Schoen <schoen at loyalty.org>      |  No haiku patents
     http://www.loyalty.org/~schoen/        |  means I've no incentive to
  FD9A6AA28193A9F03D4BF4ADC11B36DC9C7DD150  |        -- Don Marti