"The systems are highly constrained. and don't have AES in hardware." You know this for an absolute fact? AES has been a standard cell in cell libraries for decades. If it is there, then there is a mechanism which is already evaluated, and fast. [note I'm not talking about AES 256, just normal AES 128 running in OFB mode.]
[I'm not super thrilled about trading one unevaluated algorithm for another - SIPHASH] Deb On Mon, Sep 22, 2025 at 10:36 AM Alan DeKok <[email protected]> wrote: > On Sep 22, 2025, at 9:55 AM, Deb Cooley <[email protected]> wrote: > > I have no earthly idea why one would propose a protocol, TLS, for a > > function such as this. I wouldn't imagine that TLS would be fit for > > purpose in this use case. > > TLS was used just as an example of a "solution" which would be too high > overhead. > > > The question is how to generate bits in a way that is only known to the > two > > endpoints, and do that fast enough to provide a reasonably unguessable > > value to shove into packets. Classically, a stream cipher (AES in OFB > mode > > for example) is much faster than normal block cipher modes (the normal > AES > > GCM). If the CPUs in question have the AES standard cell in hardware, it > > should be fast and require less implementation to get wrong. CHA-CHA is > > also a stream cipher, but it is normally implemented in S/W, so I'm not > > sure how fast it is. > > The systems are highly constrained. and don't have AES in hardware. > CHA-CHA is a cipher, and isn't useful here. > > We need a way to authenticate the packet contents. Right now, that's > done with MD5 as Hash(packet + key). > > Failing that, the idea is to generates a stream of pseudo-random numbers > based on shared / secret state. That's the ISAAC method which we propose > here. > > Paul suggested SipHash. Perhaps it is fast enough to replace the use of > MD5 in BFD. But doing that would involve a new document. > > > If there is an instance of using ISAAC in this use case, there will be > > gigantic warnings about how this is NOT a general purpose option. I'm > not > > a fan, nor is any other Sec AD I've ever met, of picking an algorithm out > > of the blue and using it without evaluation, no matter how old it is. > > Sure. > > > Before I answer the other comments, I have some homework to do (where > does > > RFC5880 get/generate/negotiate keys since apparently I read something > > wrong). > > The keys are not generated. The keys are really shared secrets entered > by humans, in an admin interface. i.e. ASCII text. > > The keys are not negotiated. There is no way to signal "you sent me key > X, but I want to use key Y". BFD just proposes a key ID. The other end > either uses the corresponding key, or else it tears the session down. > > While there are provisions for using multiple keys, in practice, there's > really only one shared secret for any BFD peers which communicate. > > Alan DeKok. > >
