how to manually specify LUKS parameters for disk crypto?

[Jake]

did some poking around and, afaict, qubes uses LUKS with the default
parameters. i found some cryptsetup defaults at

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption

this shows that cipher, key size, (pbkdf) hash algo and iter time are
aes-xts-plain64, 256, sha1 and 1000 ms, respectively.

i'd like to change these to non-default settings, but i'm not very
familiar with the install process for qubes. as best i can tell, these
knobs are not exposed by the qubes installer and i didn't see anything
about it in the archive. i've used openbsd and bitrig for many years and
i can just drop to shell before kicking off the install and manually
configure FDE. is there a a similar process for manually configuring the
LUKS volume when installing qubes?

if there is documentation about how to do this already, i only need to
be pointed at it. clues appreciated.

regards,
jake

[Marek Marczykowski-Górecki]

On Sun, Jan 11, 2015 at 08:47:42PM -0600, Jake wrote:
> did some poking around and, afaict, qubes uses LUKS with the default
> parameters. i found some cryptsetup defaults at
>
> https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
>
> this shows that cipher, key size, (pbkdf) hash algo and iter time are
> aes-xts-plain64, 256, sha1 and 1000 ms, respectively.
>
> i'd like to change these to non-default settings, but i'm not very
> familiar with the install process for qubes. as best i can tell, these
> knobs are not exposed by the qubes installer and i didn't see anything
> about it in the archive. i've used openbsd and bitrig for many years and
> i can just drop to shell before kicking off the install and manually
> configure FDE. is there a a similar process for manually configuring the
> LUKS volume when installing qubes?

You can switch to terminal with Alt-Ctrl-F2 and create LUKS partition
manually.

> if there is documentation about how to do this already, i only need to
> be pointed at it. clues appreciated.

Nothing Qubes-specific. Maybe some Fedora documentation covers this
case.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Jake]

On 01/12/15 19:57, Marek Marczykowski-Górecki wrote:
> On Sun, Jan 11, 2015 at 08:47:42PM -0600, Jake wrote:
>> did some poking around and, afaict, qubes uses LUKS with the default
>> parameters. i found some cryptsetup defaults at
>>
>> https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
>>
>> this shows that cipher, key size, (pbkdf) hash algo and iter time are
>> aes-xts-plain64, 256, sha1 and 1000 ms, respectively.
>>
>> i'd like to change these to non-default settings, but i'm not very
>> familiar with the install process for qubes. as best i can tell, these
>> knobs are not exposed by the qubes installer and i didn't see anything
>> about it in the archive. i've used openbsd and bitrig for many years and
>> i can just drop to shell before kicking off the install and manually
>> configure FDE. is there a a similar process for manually configuring the
>> LUKS volume when installing qubes?
> You can switch to terminal with Alt-Ctrl-F2 and create LUKS partition
> manually.

marek,

thanks for the clues. i got it working after several failed attempts, so
i'll include the steps i took in case anyone else wants to tinker with
the LUKS knobs.

- boot into installer, wait for first gui screen to appear where it asks
about language/localization
- hit Ctrl+Alt+F2 on your keyboard to escape to a shell session. NOTE:
my laptop keyboard did not work properly, had to plug in a USB keyboard
- check and adjust the partitioning on the drive you plan to install to
with parted. i left the partition table as "msdos"/MBR type, created a
500 MB ext4 bootable partition with mount point /boot, and created
another partition for the rest of the disk.
- run "cryptsetup luksFormat <options> <rest of disk device>" to set the
LUKS options just so and set the passphrase
- make sure the new container works by doing "cryptsetup luksOpen root"
then "mkfs.ext4 /dev/mapper/root" to format it, then mount it, umount
it, and finally "cryptsetup luksClose root".
- everything should be set with the preparation, so hit Ctrl+Alt+F7 to
go back to the gui installer
- continue installing per the usual and when you get to the disk
partitioning/allocation part, pay attention
- when you select the disk, it will complain about only having a few MB
of space, uncheck the "Encrypt and ask me about the passphrase later"
box and hit the Custom button.
- in this menu, you should see the unencrypted boot partition and an
encrypted LUKS partition. you need to unlock the LUKS partition here,
i.e. enter passphrase.
- this next part was a bit glitchy but i managed to get it working after
a reboot. you need to set the mount points on these partitions once the
LUKS is unlocked. set the mount point for the LUKS partition as /, make
sure the encrypted box stays checked and that you check the format box
(req'd for root partition). similarly, set /boot as the mount point for
the unencrypted boot partition.
- now the install should complete without event and you have a LUKS
container with the options you set above.

i relied mainly on the 1st link listed below with some additional info
from the others.

http://thesimplecomputer.info/full-disk-encryption-with-ubuntu
https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions
http://www.cyberciti.biz/hardware/howto-linux-hard-disk-encryption-with-luks-cryptsetup-command/

regards,
jake

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jake wrote:
> did some poking around and, afaict, qubes uses LUKS with the
> default parameters. i found some cryptsetup defaults at
>
> https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption
>
> this shows that cipher, key size, (pbkdf) hash algo and iter time
> are aes-xts-plain64, 256, sha1 and 1000 ms, respectively.
>
> i'd like to change these to non-default settings

Are you prompted to change these defaults due to a special set of
needs, or do you believe them to be insecure for their intended
(general) use? Just curious.

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJUtj/rAAoJEJh4Btx1RPV8pjIP/3zWmzDcx9b10RHEArf0VE0U
3+c6v7Mh2SVNJXqU2bnXfYNMX/pQ8Bc9zPYcsIfNqztsH3omqiFgyzeBtq+FNoBx
16RtSLupTQDPJpo5zKDZ67kkKTAYl5kjcDtnY6yEQasc34P3pNF36DJEud7SIvaE
QIWR1wY5FQT8QudAg3yCE4FoHyUm3BIB/lqhpgAjWWiIyQf4SlwHvuem2XqEYsKp
Xfvdi1O9j8ZwhSDgL2kZEJyDZsn1ru6Dfp1ATotbezzlwVSL0yqu7kQFx0AYP+iP
obkzsekWysPsiO5/GMoqUgdJ5BZckLZVNx4UYqgKgWXIop1MtzwZIdGQQNXrsTmQ
bFXDXrUvXgvYjvkJ+NrG5A7qYo1piwQ34fhQ4Ba4DEKAqGvAqsuGrxyfnJOmLcoY
76aOHQqmzXY7UCOBDzi1BUtWG3jPJwNhy4fIX2hk/lA9xgxRv8B+FgWo+D8LacL4
tbTOK70Hob6qfhtbSHcj0hrgYZKAKnYTswDTblh8hJdDN+OrbDBicCZNGp7lUr+b
52c6fnwgksoZPX13ydfvfm8fconsRlMV4J5qoqHmwG4CQ7FvZ5ROTDBJLWfGuJej
4xFKvqe25tEts9BGBjp7qaxR2oDKWHe739nQUGFifB6xyrp/nxDMxEo2kjWG/wjP
P2FXpq9N5LJGOdQvZrLt
=QBcE
-----END PGP SIGNATURE-----

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

fowl...@riseup.net wrote:
>>> this shows that cipher, key size, (pbkdf) hash algo and iter
>>> time are aes-xts-plain64, 256, sha1 and 1000 ms, respectively.
>>>
>

>> Are you prompted to change these defaults due to a special set of
>> needs, or do you believe them to be insecure for their intended
>> (general) use? Just curious.
>

> Structurally speaking, they are close to finding a collision in
> SHA-1. The best result is breaking 76 of 80 rounds of the hash
> [1]. Hypothetically a full collision would take 2^61 [2], which,
> while still an enormous number, is outside of the comfort zone of,
> e.g., the NIST [3].
>
> Why not change the default to SHA256? It seems like we are at the
> beginning of the end of SHA-1.
>
> [1] http://marc-stevens.nl/research/sha1freestart/ [2]
> http://marc-stevens.nl/research/papers/EC13-S.pdf [3]
> http://csrc.nist.gov/groups/ST/hash/policy_2006.html
>

Collision resistance actually isn't relevant to passphrase hashing for
key derivation. However, what *is* relevant is the fact that SHA-1 and
SHA-256, being 32-bit operations, are extremely efficient to compute
on the GPUs and FPGAs which an attacker is likely to use, while
SHA-512 (being a 64-bit operation) is much more costly, yet not
noticeably slower on a normal 64-bit PC where the user only has to
perform the operation a small number of times. Therefore, switching to
SHA-512 makes things *much* harder for the attacker while making
things only negligibly harder for the user. This is a significant
benefit. With that in mind, my preferred LUKS command would look
something like this:

# cryptsetup -v --hash sha512 --cipher aes-xts-plain64 --key-size 512
- --use-random --iter-time 5000 --verify-passphrase luksFormat /dev/sdX

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVAzySAAoJEJh4Btx1RPV8bWAP/18ABl8o8Op5C6SUk9o/zLdX
62zdx8/G3xefgSxSRpfiQDyz4kSDsSgxQTi/MEmDK2Er2JyEo56rjolZ9HEQNV/j
eLyfY6kHnM8hWKWGlTUN0YVqUZwEfbNa3EyWdjY8RqAiVQDoFT755PWtM9ny0ybZ
nhW+lRSTZzQMDMNKBUFvezstlln36NfzD1Dpp59TrtswVx+VKnoeNEid+EQspkPZ
33OMogetZVsW+nCpjYtVZBxnayKtSAQaS1w1fsZ871e4QPgdWdi7I02X1uim2G+O
XbRhA0a+P63v8eop7QJ43hIDR4n1otS/9p4pmi9nyVV3zASFhNqObMDw5/29PLOw
IkAABERoMZfW5p6BuIRYMGEd1VRLLwH7lAottYUwEFXK5COfYTNeiAHLmsOGsDKN
3Pg9g49+CbPbfVjoaOO351qzPSo9eHogunjuQ1rBiPQMXhTiAOeLyjig3fhnQaLW
TgDcmuoyLpHHkyn/ik/y3IPfmzjQ+v2EAw/Lc0pvXBM9B+X9FKjxyx2KVTQb2Gik
Qd8MTChyE1+mbG/Vdg5OwoV+5Lk0ze2HLe9vc9W8CreBxWaN1ypEjorcmVTEq4Ov
U6NTrLIRmZPUn1SvIt1AZsreHFkYeq6lvXT+wxxf1eCn67UAkG561MHz70nupCyM
eJ0l1+liajnC01fCPF3g
=uo+o
-----END PGP SIGNATURE-----