Hi Graham,
Would the Timestamp be generated every time cycle? If this wasn't a static
figure (per timecycle - maybe when the secret is changed?, but rather a
rolling unix time), then how would the Responder be able to validate this
Cookie (without trying every previous timestamp or having the
-Original Message-
From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, December 03, 2014 10:06 AM
To: Valery Smyslov
Cc: ipsec; Graham Bartlett (grbartle)
Subject: Re: [IPsec] Some speculations about puzzles
I think it’s simpler to keep a short
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.
If the 1 byte 'difficulty level' has become the 'puzzle id', could we
break the 1 byte into two 4 bits?
1st 4 bits is 'puzzle/generation id', next 4bits is 'difficulty level',
this allows for 16 cycles for when every secret changes and still allows
16 levels of puzzles..
(just a thought as if
Why? The responder can remember that generation 8 had a 20-bit difficulty
level. If the attack then gets worse, than generation 9 is created with a
23-bit difficulty level.
The responder needs only remember the generation and associated difficulty
level.
On Dec 4, 2014, at 1:07 AM, Graham
Hi Scott,
this is almost identical to what I proposed in my original e-mail,
if you substitute difficulty level with puzzle id”.
Or call it “generation id”, and increment it whenever you generate a new
secret and/or change the difficulty level.=
That will work. In this case it is better to
On Dec 4, 2014, at 9:20 AM, Valery Smyslov sva...@gmail.com wrote:
Hi Scott,
this is almost identical to what I proposed in my original e-mail,
if you substitute difficulty level with puzzle id”.
Or call it “generation id”, and increment it whenever you generate a new
secret and/or
