Cipher selection (Was: Re: ABI guarantees)

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.