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