Fedora emergency mode after FDE LUKS failed password attempts

Ask Fedora
1

Fedora Atomic GNOME 43, full disk encryption activated. It only has happened twice but the pattern repeats, I think it could be related to FDE, I am not entirely sure! New install I had Fedora for a week.

1- After entering the wrong password three times further attempts send Fedora into emergency mode. Is this a security feature?

2- How can I save rdsosreport.txt to a USB stick in this situation? And just to make sure, could the data saved on the report or the screenshots by used by an attacker to improve brute forcing the password?

IMG_20260412_135643_HDR
IMG_20260412_135643_HDR1920Ă—1446 374 KB

2

You only get two or three attempts to enter a correct passphrase.
After that it always fails.

3

It is a default configuration. I would not call it a security feature since you can just pull out an encrypted disk and then run all the brute force attempts, with no limits.

I have actually raised the number of tries to 5, you can just append that option to the last field in /etc/crypttab:

luks-nvme0n1p3 UUID=[redacted] none discard,tries=5

Short answer: no. Longer answer: LUKS2 uses Argon2 or PBKDF2 to derive a key from the passphrase and a salt that is stored in the LUKS2 header. Nobody with a basic understanding of what a salt does would print it or include it in logs.

4

Could you please let me know, or anybody else, if the salt is visible in the screenshots?

I asked AI and it says that the salt is not secret “stored in plain text within the volume header on the disk itself.” and “designed to be public”

5

No, the “Warning:” lines only reference the UUIDs, not a salt. You can take a look at the salt by running cryptsetup luksDump on your encrypted partition:

$ sudo cryptsetup luksDump /dev/nvme0n1p3
LUKS header information
Version:        2
Epoch:          52
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           [redacted]
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          allow-discards 

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2id
        Time cost:  4
        Memory:     1048576
        Threads:    4
        Salt:       [redacted] # <- what it says on the tin, this is the salt
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
[...]

Yes (Edit: if by physical access you mean low level access to the sectors of the disk, physical access to a running machine is not enough, you would need root privileges). The point of salt is to defeat precomputation (feed all possible passwords into a one-way function and store the results). If you add a 32bit random salt to the passwords, an attacker suddenly needs to store 2^32 times the amount of data since you need to feed every combination of password with every random salt into the one-way function and store the result.

I suggest you read up on what a salt does: Salt (cryptography) - Wikipedia

6

Technically, yes, a salt is not secret. It’s not exactly public, either, since if an attacker knows the salt, they could still precompute for this particular salt.