Preservation/kaiten-yaki
1
0
Fork 0
mirror of https://github.com/suikan4github/kaiten-yaki.git synced 2025-12-20 02:21:17 -03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update the documentation

Browse source
This commit is contained in:
Suikan 2021-07-11 14:31:21 +09:00
parent f1ad8ae660
commit 40972cebaf
4 changed files with 22 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

10
appnote/an03_itertime.md
View file

@ -10,7 +10,7 @@ Let's assume there is a Ubuntu desktop system in which the disk was encrypted by
If the user mistyped the passphrase at boot, Ubuntu prompts to type a passphrase again. There is no pain. It just asks.
Now, what's happen if a user mistyped the passphrase on the Kaiten-yaki installed system. It takes a very wrong time to see the error message. And the system doesn't prompt to type again ( The prompt issue is discussed in the [AN01](an01_howtorecover.md) ). Especially, the more number of the installations in a system makes the longer duration till the error message. Sometimes this is unbearable pain to the user.
Now, let's see what's happen if a user mistyped the passphrase on the system which was installed by Kaiten-yaki. It takes a very wrong time to see the error message. And the system doesn't prompt to type again ( The prompt issue is discussed in the [AN01](an01_howtorecover.md) ). Especially, the more number of the installations in a system makes the longer duration till the error message. Sometimes this is unbearable pain to the user.
This kind of pain de-motivates users to use a long passphrase, because the longer passphrase causes more mistypes. As a result, some users may use the shorter passphrase. The bad user experience of passphrase input may help the malicious attackers.
@ -19,19 +19,19 @@ GRUB is the root cause of this slow user passphrase matching.
The passphrase is hashed and stored to LUKS key slot when a LUKS volume is created ( or, a new passphrase is added ). The stored hash value is not simple. The cryptsetup command makes hash value from the user passphrase. And then, create the next hash from this hash. And then, create a third hash from the 2nd hash, so on. This repeating is named [key stretching](https://en.wikipedia.org/wiki/Key_stretching).
The key stretching technique enforces malicious attackers using more computation resources on the brute force attacking. The more stretching iteration times require the more resources to attack.
The key stretching technique enforces malicious attackers to use more computation resources on the brute force attacking. The more stretching iteration times require the more resources to attack.
Of course, there is a balance and security strength. By default, the cryptsetup command takes the iteration needing 1 sect to calculate the passphrase hash, for the LUKS1 format. This sounds like a good balance. The cryptsetup runs on Linux when it calculates the appropriate iteration of key stretching. So, there is no problem if Linux challenges user passwords. It will take about 1 sec, by default.
Of course, there is a balance and security strength. By default, the cryptsetup command takes the iteration needing 1 sect to calculate the passphrase hash, for the LUKS1 format. This sounds like a good balance. The cryptsetup runs on Linux when it calculates the appropriate iteration of key stretching. So, there is no problem if Linux challenges user passwords. It will take about 1 sec, by default on the Linux system. 1 second is acceptable for almost users.
But there is a pitfall. On the full disk encryption system by Kaiten-yaki, the /boot is encrypted. So, to load the Linux kernel, GRUB has to decrypt the LUKS volume. That means GRUB has to calculate the passphrase hash. Unfortunately, this calculation is slower than Linux's one. Thus the user has to wait longer than 1 second.
The duration by GRUB is up to the system. It depends on the CPU. Also, In addition to this slow hashing, GRUB has to scan all used key slots when the user mistyped. For example, if 3 distributions are installed in a LUKS volume by Kaiten-yaki, 4 key slots are used. Thus, if it takes 10 seconds to challenged one hash by GRUB, this system takes 40seconds to show "The wrong password".
The duration by GRUB to calculate the passphrase hash value is up to the system. It depends on the CPU. Also, In addition to this slow hashing, GRUB has to scan all used key slots when the user mistyped. For example, if 3 distributions are installed in a LUKS volume by Kaiten-yaki, 4 key slots are used. Thus, if it takes 10 seconds to challenged one hash by GRUB, this system takes 40seconds to show "The wrong password".
This is the mechanism of the slow response at the passphrase input.
## The key stretching, the --iter-time parameter, and the vulnerability
Kaiten-yaki can relax this pain by ITERTIME configuration parameter in config.sh. This parameter is passed to the cryptsetup command as --iter-time parameter.
By setting 1000 to the ITERTIME, cryptsetup takes the key stretching iteration cycle to take 1000 milliseconds. By setting 100, it will be 100 milliseconds. It is believed the default value of --iter-time is 1000 ( Its compile default ). Thus, choosing 100 as ITERTIME makes the duration to the "Wrong password" 4 seconds, in the above example. This sounds acceptable.
By setting 1000 to the ITERTIME, cryptsetup takes the key stretching iteration cycle to take 1000 milliseconds. By setting 100, it will be 100 milliseconds. It is believed the default value of --iter-time is 1000 ( Its compile default ). Thus, choosing 100 as ITERTIME shorten the duration to the "Wrong password" from 40 seconds to 4 seconds, in the above example. This sounds acceptable.
On the other hand, the smaller ITERTIME is the weaker to the bute force attack. It is assumed the strength of the passphrase hash is linear to the ITERTIME parameter ( --iter-time parameter of cryptsetup ).