Re: Cipher selection (Was: Re: ABI guarantees)

Vadim Goncharov <[email protected]> Tue, 19 Aug 2025 17:23:30 +0300
Newsgroups gmane.os.freebsd.architechture
Message-ID <[email protected]>
On Tue, 19 Aug 2025 13:23:27 +0200
Jan Bramkamp <[email protected]> wrote:

> On 18.08.25 22:54, Vadim Goncharov wrote:
> >> For userspace I do think we want a higher bar, but I'm not sure that a bar
> >> of "no binary can ever stop working" is fully feasible.  The Secure RPC
> >> case is an example where we've removed the necessary crypto bits because
> >> they are insecure and deprecated.  I would probably rather have stubs
> >> for the libc symbols that fail immediately rather than keeping around the
> >> implementation in the Secure RPC case.  That might depend on your
> >> definition of stability.  Are stub symbols that permit an executable to
> >> still load and execute but encounter errors if using the stubs considered
> >> an ABI compat shim or ABI breakage?  What about cases where we can't
> >> support the old semantics?  In 14.0 (I think) I removed kernel support
> >> for several insecure crpyto algorithms that are formally deprecated for
> >> IPsec, and we no longer support configuring them via setkey(8) or the
> >> like.  The binaries still work, but they will get an error back from the
> >> system call if they use a deprecated algorithm.  Is that ABI breakage?  
> > Don't know about IPsec but deleting blowfish was surely a mistake - it is
> > not broken and could be used e.g. in IoT where space constraints matter,
> > for those who know what they are doing.
> >  
> Blowfish is a 64 bit block cipher that means you have to rotate keys 
> very often
> 
> and can't use certain cipher modes securely (by modern standards).
> 
> It has terrible key agility and uses key and plaintext dependent indexes 
> into large lookup tables.
> 
> In short it's a terrible cipher for IPsec and always has been, but 3DES 
> was even worse when implemented in software.
> 
> You're much better off using ChaCha20+Poly1305 on anything that lacks 
> AES+GHASH acceleration.

Of course not. I can't use it for 24-byte payload of 6LoWPAN over IEEE 802.15.4
packets because streaming cipher requires MIC of size which will simply do not
fit. CBC with 64-bit cipher fits much better here. We are not speaking about
IPsec here but on generic FreeBSD applicability in IoT (constrained devices).

-- 
WBR, @nuclight