You have to add the file as a key file. Just adding the password to the file isn't enough.
cryptsetup luksAddKey /home/user/EncryptedSD.txt /dev/sda
this post was submitted on 07 Apr 2025
20 points (100.0% liked)
Linux
9870 readers
93 users here now
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.
founded 2 years ago
MODERATORS
You have to add the file as a key file. Just adding the password to the file isn’t enough.
cryptsetup luksAddKey /home/user/EncryptedSD.txt /dev/sda
Thanks! I think you're onto something here. SOrry what's the purpose of adding the key? Does it get stored in cryptsetup's internal storage so you never have to input it again?
I'm not sure about the details but as far as I know luks has a long internal key that is used to encrypt the whole drive. This master key is encrypted with your passphrase and that encrypted key is stored on the drive.
When you add a file as a key the master key is encrypted using the binary contents of that file and stored as well. The contents of the file are basically an additional pass phrase.
So when it tries to decrypt the drive at boot it first tries to use the key file you give it. When that fails it asks for the pass phrase.
When you made the file EncryptedSD.txt it did not contain the same binary data as the pass phrase you created. Probably due to an additional newline or two. To get around that you add the whole file as it is as a valid decryption key.
Often people might create an extra long key on an extra USB stick. Or if you want to decrypt the drive automatically with the option of setting up a pass phrase later you can initially create the volume only with a key file stored on the boot drive or so.
...I think you have something here. If I create a random password and save it via nano on a brand new file, and use this file as passphrase during the initial creation...it then doesn't let me open the encrypted device. It says no key available with this passphrase. When you input the cryptsetup open, you're only allowed to manually type the passphrase (it no longer accepts a file with the passphrase, I think). Curiously, both the file and the passphrase I type manually...are pasted from the clipboard from the same password randomly generated on bitwarden and then copied to the clipboard. And yet, it seems something doesn't match.
EDIT: Seems when you 'open' with a file, the appropiate way is cryptsetup luksOpen /dev/sda encrypted --key-file /home/user/encryptedSD.txt
Since this can be easily pulled off from the laptop, I want it to be encrypted
And the laptop can be easily pulled off the desk so you might want that encrypted too.
Just partly related, and probably no help here - but about the fact, that you can't type in that password (regardless whether you can remember it or not):
you probably use a bluetooth keyboard on that surface? Before boot is finished, bluetooth connection is not possible, so you need some sort of USB/serial keyboard to even type.
Had this issue when full disk encrypting a surface, because without usb (or the original serial) keyboard your stuck in the luks mount process during boot...
Nope. Full on original surface keyboard. Works on BIOS, works on Grub...and then on that specific step, no input is reflected on the screen. No keys being typed, no failed login message being shown, nothing reacts.
Ok, typing in the password but not seeing any characters (like * e.g.) is quite common. It prevents shoulder surfers from seeing the acual length of you password.
That means, that its still possible, that you keyboard is actually working there.
Are you using a layout different from US-ANSI ? Sometimes devices fall back to US layout during boot, which would lead to you typing in a "wrong" password, without noticing it. Especially special characters have different keys on different layouts. On german layout e.g. "y" and "z" are "swapped".
Yes, I understand all this but....If I got the wrong password, I should, A) get some feedback that I have clicked Enter and attempted a login, and B) get feedback that my attempt failed, right? All I get is a frozen screen unresponsive to any input at all.
Yes, sorry for missunderstanding !
Key files should be key files that are associated with the device encryption, not just the password stored on a text file.
https://www.cyberciti.biz/hardware/cryptsetup-add-enable-luks-disk-encryption-keyfile-linux/