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.
It will be very rare to use this in a non-ramdisk circumstance. It is
different then the user 'password change' operation.
