> On Aug 26, 2025, at 10:36 AM, Alan DeKok <alan.de...@inkbridge.io> wrote:
>
> On Aug 26, 2025, at 10:27 AM, Jeffrey Haas <jh...@pfrc.org> wrote:
>>> s/secret key/shared key/ ?
>>
>> I'm going to leave this one for Alan and the security folk to answer. The
>> document mostly uses "secret key" throughout the text.
>
> The terminology could be either way. RFC 5880 uses both "secret key" and
> "shared key". I don't think either term is a show-stoppew.
In that case, let's wait for the security-AD review and then update for
consistency at that time.
>
>>>
>>> The page size of 256 sequence number is not really justified, I would
>>> naively
>>> have expected a much larger "page". Rate of 100's of pps is rather low
>>> level.
>>
>> ISAAC wasn't crafted to solve BFD's problems, we're just conveniently using
>> it. :-)
>
> The page size is a limitation of ISAAC. The only thing I know about
> cryptography is that I'm not going to invent my own version.
>
> An alternative to ISAAC would be to use a CSRNG, and then to manually
> pre-cache blocks of data. But then we have to choose a secure generator, and
> define how much data to cache. In contrast, ISAAC came with exactly the
> functionality that we need.
>
> The optimized authentication draft makes it easy to add such a construct
> later, if we so desire.
The thing that is perhaps non-obvious to someone encountering the mechanism the
first time is that the availability of pages at speed are functions of when to
spend CPU time and how much memory you wish to use.
If you find that for the speed you need for BFD that precomputing multiple
pages is necessary, nothing stops you from doing so. The generation of page
N+1 requires as an input page N. Thus, you can keep around any number of
pages, if you're willing to spend the memory.
BFD procedures mean that we need to keep around effectively two pages near
indexing into a page boundary to handle the "flip". It's necessary to pace the
generation of a page based on when BFD will want it based on transmission and
reception rates. If the cost of generating the next page is such that you
can't do it "instantly", you need to know how many accesses of subsequent keys
time-wise before you have to generate the next page. Given the possibility of
packet loss, the implementation may not be able to use access at a given index
as the trigger; timing is also a factor.
Similarly, the consumption speed of pages will be a similar factor.
ISAAC simply provides for memory conserving behaviors that are attractive for
resource constrained environments like line cards.
-- Jeff
