Hi Scott,
this is almost identical to what I proposed in my original e-mail,
if you substitute "difficulty level" with "puzzle id".
In more generic way - responder encodes in cookie/puzzle
all the information that could help him quickly
reject invalid/stale/forged puzzles without
wasting resources.
Valery.
I think it’s simpler to keep a short list (a queue actually, but usually
with no
more than 2-5 entries) or <difficulty-level ; secret> pairs.
Generate a new pair every 10 seconds or whenever the difficulty level
needs
to change. Remember all entries for the last 20 seconds. Calculate the
cookie
as described in the RFC.
When receiving a cookie, you try to validate it using all the remembered
secret-difficulty pairs (I guess you check for sufficiently many zeros
before
you check for the hash), and let them in if one such pair validated.
You can do it easier than that; encode a 'puzzle id' within the puzzle you
send to the client (and which they must send back); that way, you can look
up the puzzle you originally asked, and check the answer only against that
one.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
