[SOLVED]Set a crypto password on the hard disk

jojo06 · 2025-09-11 11:46:06

Hi,

I declined this option when installing Linux. But now I want this kind of encryption. Hard disk encryption. But I also want a special rule: if the password is entered incorrectly even once, the system will lock.

And here's the important part: if you forget your normal login password, you can reset it using a USB drive or by running a few commands from the grub/os section. I hope this doesn't apply to disk encryption?

Last edited by jojo06 (2025-09-13 21:12:04)

schard · 2025-09-11 12:45:08

How did you install "Linux"?

jojo06 · 2025-09-11 13:32:22

Umm i meant Arch Linux. But while in setup, its installing Linux right ? The kernels, core utils ? From USB ofcourse

schard · 2025-09-11 13:34:55

You said you "declined this option". What installer did you use?

seth · 2025-09-11 13:50:35

I hope this doesn't apply to disk encryption?

Not if you do it right.

if the password is entered incorrectly even once, the system will lock.

What does that mean?

For your principal question: you cannot just hand a padlock in front of your disk
See https://superuser.com/questions/216879/ … g-its-data and https://www.johannes-bauer.com/linux/luksipc/ and have backups.
In doubt consider using a vault (encrypted disk image you mount as or into your $HOME) instead.

jojo06 · 2025-09-11 13:54:10

I don't understand what you're questioning. I burn the ISO to the USB by following the steps on the wiki. I know there's only one method anyway. Why should i use/download ISO from somewhere else ? I installed from terminal tty/boot with install USB.

Don't worry too much about the `Declined` word. I honestly don't know the difference between these few words. Let's say I didn't choose this option, I didn't do this setup/configuration.

The main idea/goal is i want to encrypt my hard disk.

EDIT: @Seth thanks. Im not doing it for some data/files. I want it for accessing computer. About lock; for example, if you enter the PIN code incorrectly three times, it gets blocked. You need the PUK code. This also happens with Gmail and banks. You need to unblock it by verifying that it's you. I only want to make one chance and if pw wrong it would be blocked. Is it not possible to use software during boot, or to write this rule into the operating system/boot ?

Last edited by jojo06 (2025-09-11 13:59:15)

Succulent of your garden · 2025-09-12 01:17:54

jojo06 wrote:

About lock; for example, if you enter the PIN code incorrectly three times, it gets blocked. You need the PUK code. This also happens with Gmail and banks. You need to unblock it by verifying that it's you. I only want to make one chance and if pw wrong it would be blocked. Is it not possible to use software during boot, or to write this rule into the operating system/boot ?

I'm not sure that if that's possible, I mean the whole idea of encrypting a drive is far more than just setting a password to a drive. The reason for encrypting the drive is because with the encryption key the operative system is able to understand the content of the files encrypted, once you unlocked the drive, then that key is going to be store in ram until you power off or reboot your system. The encryption key works as a "translator" if you want to view it in that way. The operative system needs the key to understand the language, is very much a very complex cipher. Like the old roman one or the enigma machine but I guess without the issues of symmetrical encryption.

If you want to use something like a PUK code then why to have it in this case ? If you don't have the password to unlock the drive, the data is incoherent for anyone, no matter how until someone is able to introduce the correct key. If your are using a consumer grade drive like and SSD or HDD, then is most probably than the drive is unable to self encrypt himself, meaning that each time you put the key is going to be loaded to the RAM so the OS can understand the data. This is far more important than having a PUK, because in the worst case scenario someone can fetch the key after booting by trying to access the RAM address. This is very very hard to do but is possible. This possibility gets 0% if you use a self encrypted drive, which obviously costs more, since the drive itself is able to decipher the key and not the CPU which is going to put it in RAM.

The other thing that you are missing probably is the bootloader, since you have two partitions you need to encrypt also the bootloader, if you are only encrypting the home partition and not only because you want to keep your files secure in case of theft, then you probably need to encrypt the boot loader partition also, or put the bootloader in a usb stick an boot from there, or just do the UEFI booting directly if you trust your mobo manufacture probably using secure boot.

So in long story short if your don't have a self encrypt device then probably whatever you want to do in someway from a certain point of view could be in vain. But of course any intent to get the device key is very hard to achieve, can be done in theory but in practice is another thing.

You can't encrypt your device after installation if you do that everything is going to be deleted, since now the drive needs the key to understand what is going on.

Quantum computing is just a hype also just like AI, in case you are worry about quantum computers breaking RSA keys. We are still far ahead of that, I mean for the probably 4096 bits of the LUKS encrypt drive that you could have if you encrypt your drive, we are way to out of that yet, and when that comes probably the new standard is going to be making the key more larger in bits or using a quantum computer resistance cipher which already exists.

if you are creating some kind of special rule to add the PUK in reality in my humble opinion you are making nothing worth it. Maybe you can add a password for the bootloader also, but the bootloader is going to use the kernel image and the microcode cpu code that is stored, if one of those gets compromise then no matter how you try to protect your data, once you put the key of the drive in a NOT self encrypted drive, then is going to be in RAM and can be potentially fetched in theory, in practice another history. So the PUK is not going to help you in that if you don't care about checking that your are loading a healthy kernel and the correct microcode patches for the cpu, which most of the time arch linux does since all packages are going to be checked through pgp key, you will really need to really fuck it up so hard to get in that theoretical scenario which involved by passing the OS and do everything in Ring 0 level, which is also hard to make, I mean all the stuff that I'm talking here is just for real elite hackers who had some access to a computer by some stupid decision done by the user. Or you are using an asus SOHO router LoL.

The most important thing is to monitor your computer and network, that is far more important and is going to give you information in case something strange happen more quickly. The gateway router in your home is far more important than your main computers, that's it.

Maybe you can use a yubikey to have the key on it to boot https://wiki.archlinux.org/title/YubiKey but that's not a condom, I mean you need to take care of each part of the booting process, the kernel image, the cpu microcode, etc, and also failing because secure boot is not 100% secure LoL ^^

Long story short: Just put a very large psswd to the drive, up to 16 characters you are really making it hard to decipher using brute force method or any kind of sophisticated method. Up to 20 characters and above you are really into decipher the thing in the lifespan of the universe, unless the super quantum computer exists, which is not going to happen any time soon.

Also

Last edited by Succulent of your garden (2025-09-12 01:34:13)

jojo06 · 2025-09-12 02:08:42

Thank you very much for your detailed and thorough response. I must say I had no idea the matter was this complicated

The PUK incident is just one example. I don't remember exactly if it was Enigma, but I heard something like this: if the wrong code is entered, the chamber inside breaks. And there is a strong acid inside this chamber. This spills onto the parchment and destroys it.

Actually, my goal is very simple. I like where you're from And the last picture is very meaningful/significant. My point here is this: if I am asked for a password (as in the cartoon), I will of course provide it. But let's say that after one incorrect password is entered into this system, the system locks up. My memory isn't very good, so I might have said it wrong If they force me still; then, of course, I'll tell them about this situation. Something like that...

So, for example, can't this be done; /dev/sda is encrypted. It asks on the black screen during boot. Can this be bypassed (I'm not talking about elite individuals with superior cyber skills)? If it can't be bypassed and the system can't be accessed, and data can't be accessed from the hard disk, then I want to use this method. But I want to modify the kernel and/or that system/my computer. When I looked online, they were using the `cryptsetup` and `cryptdisk` packages. For example, if it's open source or if I can find open source, can I add the rule I want?

For example, many places, including Instagram, allow three attempts. Then, even with the correct password, you can't log in without email confirmation. Some systems have a cooldown period. They block IP addresses. Let's say the only thing we can do is add a cooldown period, which works for me. But it shouldn't be written in the terminal

seth · 2025-09-12 07:16:53

Sorry, didn't see your edit.
The PIN/PUK thing will not work as it relies on the attacker not having any control over the HW which LUKS is meant to provide/emulate itfp.
Let's say you've a key entering system that does this: it's in the unencrypted realm, so it can be manipulated. I win.

I guess one could write a key entrance system that will discriminate the provided password and destroy the system (IMF-style) if it's wrong, but you'd also have to force the attacker to use that system.
What you *can* do is to use https://wiki.archlinux.org/title/Dm-cry … der_on_USB and swallow the USB key.
Just hope that none of the attackers has seen 24, Day 8 and/or /is/ Jack Bauer…

jojo06 · 2025-09-12 10:01:11

No worries.

This is unrelated, but is the movie title “Day 8” correct? I found the one with 24, but I couldn't find the other one. I want to watch it.

So, are these methods secure as tails and its similars ? Or is it essentially the same method? Will they all work for me in the same way?

Succulent of your garden · 2025-09-12 11:16:19

jojo06 wrote:

So, are these methods secure as tails and its similars ? Or is it essentially the same method? Will they all work for me in the same way?

No, because tails is a OS that is only going to work for session only, means that any I/O operation is going to be only in ram, once the system is shutdown everything is going to be deleted. That's what they promoting as a product, which any usb stick iso does, but tails probably does the thing with adding more features on it. What Seth is suggesting is to have some part of the bootloader in a usb stick, which behaves more like a real life token for you system, which is going to ask every time in order to boot the computer, without it the system can't. Not necessarily is better in any case since in theory anyone could boot into an usb stick iso and change the boot priority in your BIOS/UEFI and boot into another OS.

jojo06 wrote:

For example, many places, including Instagram, allow three attempts. Then, even with the correct password, you can't log in without email confirmation. Some systems have a cooldown period. They block IP addresses

That's works because t uses an IP address as you said, which you don't have in the encrypt process, also Java Script and a horde of lawyers dreaming to get more money from a case against or in favor a corporation LoL.

jojo06 wrote:

So, for example, can't this be done; /dev/sda is encrypted. It asks on the black screen during boot. Can this be bypassed (I'm not talking about elite individuals with superior cyber skills)? If it can't be bypassed and the system can't be accessed, and data can't be accessed from the hard disk, then I want to use this method. But I want to modify the kernel and/or that system/my computer. When I looked online, they were using the `cryptsetup` and `cryptdisk` packages. For example, if it's open source or if I can find open source, can I add the rule I want?

You can lock your BIOS/UEFI and each time you boot is going to ask for a password, if you fail a certain amount of times [not sure if you can configure the failure times, probably is going to depend of the BIOS/UEFI] then the system is locked, and then you will need to introduce the manufacture password, which is going to depend with the mobo/notebook/laptop series. The worst case you will need to made a call to the manufacture to get it, or you can see if your system had been pwned and is over here: https://github.com/bacher09/pwgen-for-bios which does have the manufacture keys of the machines that had been already been pwned basically in long story short. I had to do it one time because I locked a system and it was in the pwned list so I was able to use that computer again. Is [sorry for the captial letters here but I must] SOMETHING THAT I SHOULD NOT RECOMMEND TO USE, ALSO YOU NEED TO BE 100% YOUR SYSTEM IS ON THE LIST, WHICH SOMETIMES IS HARD TO KNOW, THE MANUFACTURE IS NOT GOING TO GIVE YOU THE PSSWD SO EASILY IT'S GOING TO BE A PAIN IN THE ASS. But since you are asking that's another option.

Also you can by pass user login using grub config. So when you boot you will just be into root user session without asking any password. So in practice in reality if someone get's your computer physically it can boot to it by different approaches without using the xkcd comic. The only main thing is that without the psswd for the drive there are not going to be able to get the info, unless Jack Bauer came into your house knocks you out into the floor and puts liquid nitrogen in ram, so uncle Jack Bauer can make a copy of the RAM content and therefore can search for the encrypted psswd using hexdump in another computer LoL

seth wrote:

Just hope that none of the attackers has seen 24, Day 8 and/or /is/ Jack Bauer…

Or is friend of Jason Bourne.

seth · 2025-09-12 13:30:08

I think it happens in this episode: https://www.imdb.com/de/title/tt1463808/ (and just noticed Rami Malik was in that…)

So, are these methods secure as tails and its similars ? Or is it essentially the same method? Will they all work for me in the same way?

idk, but tails is a read-only live distro - that's not comparable or related.

jojo06 · 2025-09-12 13:33:31

Not necessarily is better in any case since in theory anyone could boot into an usb stick iso and change the boot priority in your BIOS/UEFI and boot into another OS.

Things got even more complicated, I lost it So what I actually want is this: I don't want anyone to be able to access not just the files, but also the browser and the websites visited, passwords, etc. I want an unbreakable login password. What makes it unbreakable here, and what I actually want, is that this password is limited to one attempt. So if attacker boot into another OS, well he cant access my OS ? I didn´t get it...

But (I think) as far as I understand; this is a very big and nearly impossible task? And/or it could break in a way that wouldn't be worth all this effort?

So the only thing that can be done under normal circumstances is to use the USB method?

Also let me ask this: Can the other methods mentioned only be decrypted by elite hackers?

seth · 2025-09-12 13:49:58

What makes it unbreakable here, and what I actually want, is that this password is limited to one attempt.

Except of course they can try the "PUK".
Alternatively shred the device IMF style when a false password is entered.

Can the other methods mentioned only be decrypted by elite hackers?

It can be decrypted by anyone with a wrench and access to your knees.
What is a "elite hacker"? The NSA? Some industrial spy? Some mean kid in your class? Your sister?

You're approaching this backwards: you have a thing of value and an expected thread. Then you start to figure what is necessary to shield the thing of value from the thread.
Using a detached luks header and keyfile is probably as good as it gets because w/o the usb key that has these things, it's virtually impossible (the NSA has A LOT of computing power, though) to decrypt the disk.
The pin/puk thing is a complete kludge, because a 4 digit PIN can otherwise trivially be brute-forced manually.

You can combine these approaches w/ eg. a yubikey or smartcard which store the actual key and provide a pin/puk feature to shield access (next to just physically having the key/card)

Succulent of your garden · 2025-09-12 14:21:14

Yep is more like what seth had just said.

jojo06 · 2025-09-12 16:29:56

The PIN/PUK issue is just an example. For example, after three attempts, a rule is applied. And three attempts are allowed. Here, there will be no PUK or three attempts.

It can be decrypted by anyone with a wrench and access to your knees.

That's where the one wrong attempt comes into play. You'll say the password. But you'll say it wrong. Then let them do what they want, that's the situation, you explain it. That's where they get stuck.

What is a "elite hacker"? The NSA? Some industrial spy? Some mean kid in your class? Your sister?

NSA lets say, or cyber security team of police.
For example, persons who will not be contacted unless the incident concerns the state and/or terrorism.

Is a separate luks header and keyfile a different option from USB? So I think the disagreement/confusion arises here: I'm using the translation too, but I couldn't quite grasp the main points. Could you please list the simple methods and provide a brief explanation for each?

[Sorry for the capital letters here, but I must]

For example, I didn't understand this part at all. If only my system is on the list, can this method be used? To find out, should I run that git repository?

I believe the BIOS/UEFI method is limited to specific motherboards, and otherwise it's impossible, but is it doable otherwise? By contacting the manufacturer, do you mean they can provide this password (let's call it PUK)? If so, are you saying this is also a vulnerability? Is this link/method a known query method? Also, if it creates a second password field, it doesn't seem worth all this trouble. If I run the repo, it won't cause any harm, right? I think the issue here is sharing this list with the manufacturer and stating that I am entitled to receive the password, that I am compelled to do so... Have I understood correctly?

Returning to the grub method yes, the threat is physical and comes back to the method of “confessing the password” that I mentioned. And I guess this counts as the second method?

You can combine these approaches w/ eg. a yubikey or smartcard which store the actual key and provide a pin/puk feature to shield access (next to just physically having the key/card)

Its kinda luxury for now. And i guess you get me wrong @seth, im on defending side is luks method will work with keyfile ? and that will be acessable by USB ? So its 3 in 1 right, not 3 methods/steps, thats once.

So i believe there is 2 methods only ?

I guess one could write a key entrance system that will discriminate the provided password and destroy the system (IMF-style) if it's wrong, but you'd also have to force the attacker to use that system.

Oh that answer my question i guess So method 2 requires to combine with method 1.

you will really need to really fuck it up so hard to get in that theoretical scenario which involved by passing the OS and do everything in Ring 0 level, which is also hard to make

damn harder than coding and OS ?

This is far more important than having a PUK, because in the worst case scenario someone can fetch the key after booting by trying to access the RAM address. This is very very hard to do but is possible. This possibility gets 0% if you use a self encrypted drive, which obviously costs more, since the drive itself is able to decipher the key and not the CPU which is going to put it in RAM.

Thats the one and only option i guess ? Is this a winner ?

It was loud thinking, trying to understand. Hope it sounds a good answer/thinking and not stupid.

Last edited by jojo06 (2025-09-12 16:30:43)

seth · 2025-09-12 19:36:38

Is a separate luks header and keyfile a different option from USB?

No, you'd typically keep those on a USB key.

I'm using the translation too, but I couldn't quite grasp the main points.

https://deepl.com/

Could you please list the simple methods and provide a brief explanation for each?

You mean more concise than https://wiki.archlinux.org/title/Dm-cry … der_on_USB ??

Last edited by seth (2025-09-12 19:36:49)

Succulent of your garden · 2025-09-12 22:39:31

Thats the one and only option i guess ? Is this a winner ?

Yes it does, if you can have a self encrypted device then that is always going to be the better option no matter how.

For example, I didn't understand this part at all. If only my system is on the list, can this method be used? To find out, should I run that git repository?
I believe the BIOS/UEFI method is limited to specific motherboards, and otherwise it's impossible, but is it doable otherwise? By contacting the manufacturer, do you mean they can provide this password (let's call it PUK)? If so, are you saying this is also a vulnerability? Is this link/method a known query method? Also, if it creates a second password field, it doesn't seem worth all this trouble. If I run the repo, it won't cause any harm, right? I think the issue here is sharing this list with the manufacturer and stating that I am entitled to receive the password, that I am compelled to do so... Have I understood correctly?

Let me explain this a little bit: Manufactures makes signatures into the hardware. For example CPU manufactures sign the CPU patches with a secret key, that secret key is pair to each cpu of the manufacture. Let's say they have a "global key" and you in your cpu a local one. The CPU is only going to use the patches signed by the "global key". So if someone just make public the "global key" then you can create third party patches.

The same principle happens here. Almost all computer manufactures does have some "global key" or "master key" if you want to call it that way to unlock any BIOS/UEFI that has been locked by many user attempts. So you don't need to download the repo, the repo is just a collection of already know "master keys" that had been made public by many reasons. Probably boring people. I will tell you that better don't try that, it's not a good approach since anyone can know that key if they know that they exists. This is only going to work for people like your sister or a kid. Tech savy people like me or seth are going to know that the repo exists and therefore able to unlock the BIOS/UEFI.

Long story short: It's a backdoor to unlock locked BIOS/UEFI made by the manufactures.

damn hmm harder than coding and OS ?

It's going to depend on how dumb is the user. If they don't click in internet advertisement then yeah, probably coding is more harder.

It' seems that you are understanding something different than I with OS. OS means Operative System. Not sure what you mean with harder than operative system. Please use deepl.com

Last edited by Succulent of your garden (2025-09-12 22:41:51)

jojo06 · 2025-09-13 03:11:45

I already use Deepl. If they're clicking on internet ads, shouldn't it be more difficult? I don't understand the irony/joke here.

By OS, I mean the operating system. Writing Linux starting from the kernel. You've probably heard of this. Is there an article or explanation about it? What I want to do is very simple. DE is already ready. My only expectation is that it has a browser and can connect to the internet (ethernet or wifi), that's enough for me.

Or is there a different, unexpected but easy method? For example, KDE wallet manager? Without entering this, there will be no access to passwords, and it will ask for a password every time you boot. Otherwise, the passwords in memory (sessions, remember me options, and saved passwords) will become unusable. Is there no such package that allows a single attempt, or can this be modified in some way?

Succulent of your garden · 2025-09-13 12:26:57

jojo06 wrote:

Is there an article or explanation about it?

The arch wiki, Gentoo handbook and linux from scratch, and also https://www.kernel.org/ which the oficial linux kernel page. Those are probably the best resources to understand everything apart of reading the man pages and probably watching some old VHS video from the bell labs explaining Unix.

You can also go to dev.to webpage and search for topics. There is page https://devdocs.io/ which does provide almost all documentation for programming. You can use it to learn bash for example.

jojo06 wrote:

Or is there a different, unexpected but easy method? For example, KDE wallet manager?

The KDE wallet is launched after all the Init process and booting of the system, it doesn't have any sense what are suggesting. That program can't do what are you trying to do. I recommend you to learn how a computer boots in detail to understand what we are trying to saying to you here in the forum. Learn how Init systems works, how the bootloader loads the kernel,cpu microcode and do the mounting of drives properly in a encrypted device and how BIOS/UEFI is implicated in all of this. After that go and read all this forum post again, you will understand way to more what we are trying to say to you. If you have any doubts after that you can reply here, no problems, but please do the learning process, I'm 100% that you don't know how the booting process works or deepl does have very bad support for your language by some reason.

EDIT: I forget to respond this.

jojo06 wrote:

I already use Deepl. If they're clicking on internet ads, shouldn't it be more difficult? I don't understand the irony/joke here.

It means that if the user just click to anything in the internet, probably the chances to get hacked pretty bad are very low, making very easy to get into that situation. But if the user is more wise then probably coding is more harder, because it's not going to end in the hacking thing easily.

Last edited by Succulent of your garden (2025-09-13 12:31:22)

Arch Linux

#1 2025-09-11 11:46:06

[SOLVED]Set a crypto password on the hard disk

#2 2025-09-11 12:45:08

Re: [SOLVED]Set a crypto password on the hard disk

#3 2025-09-11 13:32:22

Re: [SOLVED]Set a crypto password on the hard disk

#4 2025-09-11 13:34:55

Re: [SOLVED]Set a crypto password on the hard disk

#5 2025-09-11 13:50:35

Re: [SOLVED]Set a crypto password on the hard disk

#6 2025-09-11 13:54:10

Re: [SOLVED]Set a crypto password on the hard disk

#7 2025-09-12 01:17:54

Re: [SOLVED]Set a crypto password on the hard disk

#8 2025-09-12 02:08:42

Re: [SOLVED]Set a crypto password on the hard disk

#9 2025-09-12 07:16:53

Re: [SOLVED]Set a crypto password on the hard disk

#10 2025-09-12 10:01:11

Re: [SOLVED]Set a crypto password on the hard disk

#11 2025-09-12 11:16:19

Re: [SOLVED]Set a crypto password on the hard disk

#12 2025-09-12 13:30:08

Re: [SOLVED]Set a crypto password on the hard disk

#13 2025-09-12 13:33:31

Re: [SOLVED]Set a crypto password on the hard disk

#14 2025-09-12 13:49:58

Re: [SOLVED]Set a crypto password on the hard disk

#15 2025-09-12 14:21:14

Re: [SOLVED]Set a crypto password on the hard disk

#16 2025-09-12 16:29:56

Re: [SOLVED]Set a crypto password on the hard disk

#17 2025-09-12 19:36:38

Re: [SOLVED]Set a crypto password on the hard disk

#18 2025-09-12 22:39:31

Re: [SOLVED]Set a crypto password on the hard disk

#19 2025-09-13 03:11:45

Re: [SOLVED]Set a crypto password on the hard disk

#20 2025-09-13 12:26:57

Re: [SOLVED]Set a crypto password on the hard disk

Board footer