> From: "Theo de Raadt" <dera...@openbsd.org> > Date: Fri, 11 Aug 2023 08:50:32 -0600 > > Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > Date: Fri, 11 Aug 2023 11:13:23 +0000 > > > From: Klemens Nanni <k...@openbsd.org> > > > > > > On Mon, May 08, 2023 at 11:00:27AM +0000, Klemens Nanni wrote: > > > > On Sun, Apr 23, 2023 at 05:07:30PM +0000, Klemens Nanni wrote: > > > > > For new installs, it seems adequate to base the number on the actual > > > > > hardware, > > > > > assuming the CRYPTO volume will stay in that hardware for a while. > > > > > > > > > > The current default of 16 is from old PKCS5 PBKDF2 times and changing > > > > > it in > > > > > bioctl(8) is a more invasive change (for later, perhaps). > > > > > > > > > > Thoughts? Feedback from the crypto folks appreciated. > > > > > > > > > > On X230 and T14, 16 feels pretty instant, whereas 'auto' takes about > > > > > a second > > > > > on a T14. > > > > > > > > Ping. > > > > > > Anyone? > > > > > > I consider a hardware based value a saner default for new installations > > > (root disk volumes are most likely to stick around on the same machine) > > > than a decade old constant. > > > > See the recent discussion about _bcrypt_autorounds() in libc. > > > > System performance varies, and even on modern hardware it can provide > > varying results. The ramdisk environment is considerably different > > from the mult-user environment in this respect. > > > > Using a fixed value is way more predictable. If 16 no longer is a > > safe default it should be raised. > > I think this case is different, because the ramdisk has no process > contention. > > The code still sticks to minimum 16: > > if (r < 16) > r = 16; > > On faster machines, it will increase the rounds. For that machine, for > that disk configuration. This is processed early on to bring the disk up, > when there is little or no contention. So it will not have a regressive > performance impact.
So the man page just lies?
