You are not logged in.
Pages: 1
I am building laptop for my wife and since I'm encrypting my filesystem I thought I'll give grub cryptodisk a try.
I got it to the point the system boots after asking me a single password (second one is passed via key loaded through cryptokey parameter)
It does not take long for laptop to get to first password. And the only problem I have is that after issuing first password computer freeze for about 5 minutes.
I tried enabling verbose boot log by adding `verbose` to kernel option but log still does not contain anything I can use to try to troubleshoot this.
systemd-analyze says the system boots in 7 seconds, so the problem must be before kernel is loaded.
For a test I removed rootfs:/path/to/key and I can see the big chunk of this 5 minutes delay is between first (grub) password and second (kernel). The split of this timeout is about half/half (before second password / after second password)
Can it be that kernel is still trying to find the default key (/CryptKey.bin)? I don't experience such timeouts on other system where I enter password from keyboard.
Or maybe one of hooks is taking longer to load? My mkinitcpio hooks chain is `base udev autodetect modconf block keymap encrypt filesystems keyboard fsck shutdown` and I also load dm_mod module (as per wiki)
I don't know grub well enough to reason why does it take such a long time between the two passwords. Live-dvd loads in no time (though, no encryption is involved).
---
EDIT: I have found this thread and it points iter-time can be causing the problem because GRUB may be using ineffective crypto library: https://bbs.archlinux.org/viewtopic.php?id=217193
My iter-time is 5000 and cryptsetup benchmark is quite positive on speeds even for much bigger values...
---
EDIT: Problem solved. This article gave me a hint (see last post for details): https://bbs.archlinux.org/viewtopic.php?id=217193
In short - I used to encrypt my hard drive like this:
cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random --verify-passphrase luksFormat /dev/sda3This works fine if boot partition is not encrypted. As soon as boot crypto is used it takes ages to go through 5000 iterations. As far as I understand `iter-time` is a mechanism that should make brute-force attacks harder so making it lower adds a bit of a risk that brute-force attacks will be easier to perform. As far as I'm aware mitigation is to use long pass phrase and that's what I'm going to do.
So I ended up encrypting my hard drive like this:
cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 50 --use-random --verify-passphrase luksFormat /dev/sda3And ensuring password is longer than 40 characters.
Last edited by Gregosky (2017-03-31 13:02:09)
Offline
Pages: 1