From f21ac146ba39b8fb709c38609f8a4019240c3ff6 Mon Sep 17 00:00:00 2001
From: TommyTran732 <57488583+tommytran732@users.noreply.github.com>
Date: Sun, 25 Jul 2021 11:13:41 +0000
Subject: [PATCH] Update README.md

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 6548f2e..ab18087 100644
--- a/README.md
+++ b/README.md
@@ -65,4 +65,4 @@ Ideally, I could use GRUB's GPG verification for the initramfs and its configura
 
 As for why LUKS1 is used, GRUB 2.06 does not work nicely with LUKS2 yet. grub-install will not make GRUB auto detect the LUKS2 partition, and GRUB itself does not support Argon2id (cryptsetup default) as of now anyways. In my opinion, it makes little sense to use GRUB with LUKS2 in its current state, thus I am using LUKS1 to avoid the headache for the time being.
 
-You may also see an a keyfile being created by the script and stored at /cryptkey. This is to avoid getting 2 encryption password prompts (one for GRUB to decrypt the disk so that it can get to the kernel, the initramfs and configuration files and one for the kernel itself to start up the rest of the boot process). As the key resides on an encrypted partition (and so does the initramfs that stores a copy of it), security risks should be minimal. The only time an attacker would have access to it is when they have root, at which point you have a much, much more serious proble). The procedure I am using is describe at https://en.opensuse.org/SDB:Encrypted_root_file_system.
+You may also see an a keyfile being created by the script and stored at /cryptkey. This is to avoid getting 2 encryption password prompts (one for GRUB to decrypt the disk so that it can get to the kernel, the initramfs and configuration files and one for the kernel itself to start up the rest of the boot process). As the key resides on an encrypted partition (and so does the initramfs that stores a copy of it), security risks should be minimal. The only time an attacker would have access to it is when they have root, at which point you have a much, much more serious problem). The procedure I am using is describe at https://en.opensuse.org/SDB:Encrypted_root_file_system.