-
Notifications
You must be signed in to change notification settings - Fork 1
/
cryptosd.conf
47 lines (42 loc) · 3.02 KB
/
cryptosd.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
# This configuration file is part of the crypto-sdcard utility, see https://github.com/Olf0/crypto-sdcard/
# crypto-sdcard evaluates configration files at these location in the following order:
# A file listed lower (i.e., evaluated later) can override settings made by an earlier one.
# /etc/systemd/system/cryptosd.conf
# /etc/crypto-sdcard/cryptosd.conf
# Plus at last either device-specific configuration file:
# /etc/crypto-sdcard/cryptosd@crypto_luks_<UUID>.conf
# respectively /etc/crypto-sdcard/cryptosd@crypto_plain_<device-name>.conf
# Do not alter or remove /etc/systemd/system/cryptosd.conf, because it will be redeployed by the next
# update of crypto-sdcard! Instead alter mount-sdcard's settings by creating one of the configuration
# files in /etc/crypto-sdcard/: I.e., set or reset (per e.g., UDISKS2_MOUNT_OPTIONS="") specific options
# there.
# The option variables must be in "environment format".
# All available option variables are listed here:
# 0. Preface: "On cryptography options"
# For a more detailed guide to reasonable cryptography options (for section 2.), see section 4.3.1 of
# https://together.jolla.com/question/179054/how-to-creating-partitions-on-sd-card-optionally-encrypted/#179054-43-dm-crypt-encrypted
# 1. Cryptsetup options for opening LUKS "containers"
# Because 'cryptsetup luksOpen' extracts all its cryptography parameters (and more) from the device's
# LUKS header, there is currently nothing to set for opening LUKS "containers".
# 2. Cryptsetup options for opening "plain containers"
CRYPTO_PLAIN_CIPHER="aes-xts-plain"
# "aes-xts" is the only reasonable choice, the sole alternative (but much older, slower etc.) is
# "aes-cbc-essiv:sha256". "-plain64" is unnecessary on devices guaranteed to be smaller than 2 TB,
# which is implicitly the case for all MBR-formatted (i.e., non-GPT) devices. All other cipher
# algorithms available across all SFOS devices' kernels are crytographically broken (e.g., -cbc
# without -essiv:, -ecb, -ctr, etc.), even slower and / or not widely used.
CRYPTO_PLAIN_KEYLENGTH="256"
# Note that XTS splits the key used in two halves, so the block cipher algorithm (e.g. AES) is only
# fed with half of the key length (the other half is used in the XTS chaining algorithm)!
# Consequently, to set the AES key length to 128 bits, one has to specify "128" for CBC, but "256" for
# XTS.
# Using an effective ("real") 256 bit key-length (instead of 128 bits) is slower (> 25%) without being
# significantly more cryptographically secure.
CRYPTO_PLAIN_PASSPHRASE_HASH="sha1"
# This is solely used for hashing the passphrase down to 160 bits, (only) for which sha1 is still fine.
# RIPEMD160 is not supported by SFOS kernels, the output of any other hash algorithm with a digest
# size of > 160 bits is truncated to 160 bits, and the use of any other hash algorithm with a digest
# size of < 160 bits is cryptographically insecure.
# 3. Options for 'udisksctl mount'
# UDISKS2_MOUNT_OPTIONS="-o noexec"
# Mind that udisks2 filters mount options against a whitelist: If not on that list, it refuses to mount.