Re: The official disk encryption guide seems a bit lacking (detailed list of concrete improvement suggestions!)

[Greg Troxel <gdt%lexort.com@localhost>]

nia <nia%NetBSD.org@localhost> writes:

> On Wed, Oct 28, 2026 at 12:01:33AM +0100, Ellie wrote:
>> ## 3rd thing I missed, more in-depth crypto parameter discussion:
>> 
>> The disk guide also suggests AES-CBC 256 instead of AES-XTS 512. That seems
>> a little outdated.
>
> I asked about this a while ago, and was told that the implementation
> of AES-CBC in cgd(4) offers theoretical better security. AES-XTS
> offers theoretical better performance. But I think you'll struggle
> to notice the difference between the two in practice.

It would be interesting from someone(tm) to make performance
measurements of all 3 approaches, but I too would be surprised if the
difference between the two AES approaches really mattered.  Perhaps on
slow machines with no hardware AES.   It would be even cooler for
someone to write a test script that used vnd on tmpfs and then cgd on
that, so that others could easily run tests.

> We should probably recommend adiantum because not-all-the-worlds-an-
> x86(tm).

cgd(8) already says "generally provides the best performance on machines
without CPU support for accelerating AES." and that seems appropriate.

I don't think we should recommend adiantum in general, and it probably
deserves a comment about the degree of cryptographic security it
provides.  It strikes me as off the beaten path and and having had much
less scrutiny.

It would help the man page to characterize CPU types with AES support.
If the obvious guess that AES-CBC and AES-XTS are both done in hardware
with CPUs that "support AES", it would be great if that were clearer.

Reading wikipedia, it seems that almost all x86 processors in the last
12+ years have AES support.  Even my (getting to be too slow to use) PC
Engines apu2 has it.

Beyond x86, wikipedia says there is hardware support on sparc after
2011.  It says most aarch64, but a RPI4 seems to lack it..  RISC-V is
less clear.  That leaves out (32-bit) armv7, and retro arches.