[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Password questions, looking for opinions. cryptsetup question too.
From:       Rich Freeman <rich0 () gentoo ! org>
Date:       2023-09-19 9:58:37
Message-ID: CAGfcS_kV0GmqH3-vxpLOVM+kbNR5kocUqKp0tGhJPeFm3p8eOQ () mail ! gmail ! com
[Download RAW message or body]

On Tue, Sep 19, 2023 at 4:26 AM Michael <confabulate@kintzios.com> wrote:
>
> On Tuesday, 19 September 2023 06:36:13 BST Dale wrote:
> > Howdy,
> >
> A strong
> password, like a strong door lock, buys you time.  Hence the general
> recommendation to change your passwords frequently.

While that can help on websites, it is of no use for full disk
encryption passwords - at least not without jumping through some big
hoops.

In order to crack your LUKS password somebody obviously needs to be
able to read the encrypted contents of your disk.  They cannot begin
cracking it until they have a copy of the LUKS headers.  However, once
they do have it, they can make a copy and crack it at their leisure.
If they manage to crack it, then it will give them the volume key.  At
that point if they were able to make a full copy of your disk they can
read whatever was on it at the time.  If they can make a fresh copy of
your disk then changing the passphrase will not change the volume key,
and so they'll be able to read what is currently on your disk.

Changing the volume key would defeat this, but requires running
cryptsetup-reencrypt which will take considerable time/CPU, though it
sounds like it can be done online.

> > In the real world tho, how do people reading this make passwords that no
> > one could ever guess?

You didn't ask this question, but I'll just note that most
organizations don't use human-readable passwords to implement full
disk encryption. The most commonly used solution is to use a TPM to
measure the boot process and secure the disk encryption keys.  If the
system is booted normally, the bootloader can read the encryption keys
from the TPM and can decrypt the disk without any user interaction (or
even awareness it is happening).  If the system is booted from
alternative media, or the on-disk bootloader is tampered with, or even
if the firmware is tampered with, then the TPM measurements will not
agree with those used to store the key, and the TPM will not allow the
keys to be read.

This is how solutions like Bitlocker work.

The components for this exist in the Linux world, but I'm not aware of
any distro/etc actually implementing this with a pretty front-end, and
there are obviously details that need to be carefully handled so that
a bootloader or firmware update doesn't render your disk unreadable.
Typically software implementations have ways to store "recovery keys"
for these situations (just another copy of the disk key stored outside
the TPM).

> You can use gpg, or openssl, or app-admin/apg, or app-admin/pwgen, to generate
> random enough strings to use as passwords.

You might want to also consider app-admin/xkcdpass

> > Also, I use  cryptsetup luksFormat -s 512 ... to encrypt things.  Is
> > that 512 a good number?  Can it be something different?  I'd think since
> > it is needed as a option, it can have different values and encrypt
> > stronger or weaker.  Is that the case?  I've tried to find out but it
> > seems everyone uses 512.  If that is the only value, why make it a
> > option?  I figure it can have other values but how does that work?

You can use a different size, but 512b is the recommended value for
the default cipher.  It is also the default I believe, so there isn't
much point in passing it.  Actually, I'd consider passing that
parameter harmful unless you also specify the cipher.  If in the
future the default changes to some other cipher, perhaps 512b will no
longer be appropriate, and you'll weaken it by specifying one and not
the other.

If you just want to trust the defaults, then trust the defaults.

As to why 512b is the recommendation, that seems like it would require
a LOT more reading.  Apparently it is in an IEEE standard and I'd need
to grok a lot more crypto to appreciate it.

-- 
Rich

[prev in list] [next in list] [prev in thread] [next in thread]