On Sep 29, 2025, at 9:51 AM, Deb Cooley <debcool...@gmail.com> wrote:
>
> If ISAAC is indeed quick enough, as it is basically just a different stream
> cipher (i.e. RC4) than the one I suggested. It has been asserted to be,
> but since there are no implementations, are you sure? [the case you
> presented stated that AES256 was too slow, but apparently AES128 is not.]
The ISAAC page says that it takes an average of 18.75 clock cycles per 32-bit
number generated.
https://www.burtleburtle.net/bob/rand/isaacafa.html
The various stats I can find for AES-128 claim 1.3 clock cycles per byte for
hardware implementations, and 180 cycles per byte for software. Various papers
using SIMD instructions show numbers in the 30-40 range.
For AES-128, let's assume that that we can get 4 32-bit numbers from one 16
byte block of AES-128 data. Hardware hardware implementations are then ~5
clock cycles per 32-bit number, and software implementations are 100-400 clock
cycles per 32-bit number.
But we're not using AES-128 for encryption here. We're just using is as a
CSPRNG. So AES-128 is only a solution if we can guarantee that all
implementations have hardware support for it.
The attacks on BFD aren't about gaining access to secret data. The BFD
packet contents are public. So securing BFD via some kind of encryption is not
appropriate.
We're left then with impersonation attacks. And any impersonation attack is
strongly mitigated by the fact that impersonating a BFD peer doesn't really
allow the attacker to do anything. A much better attack is to simply cut the
wire, so that the entire connection goes down. And no amount of security can
protect from that.
> The only other sticking point is reuse of the Secret Key for both ISAAC and
> the key hashes. Technically, this makes the keyed hashes less robust.
> Extraction of a Secret Key from ISAAC compromises the keyed hash versions.
There should be text in the document forbidding the use of the ISAAC key with
any other BFD authentication method. If there isn't any, we can add some.
The worst case would be someone using the ISAAC key with the BFD method of
"send the password in clear text", which would bypass all security.
> If ISAAC is literally the only stream cipher that is quick enough, then I'm
> happy to help construct words to dissuade any other use of that algorithm
> for other purposes.
It certainly looks that way.
An alternative to ISAAC would be a fast hash that could authenticate the
entire packet contents. But there are few hashes which are both fast, and
proven to be secure.
Proposed text:
The suitability of ISAAC as a solution is due to the unique needs of BFD. The
ISAAC generator has had minimal security analysis, and is therefore not
suitable for use in any protocol other then BFD.
Alan DeKok.
