cryptsetup merge requestshttps://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests2017-08-12T17:32:23Zhttps://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/27Fix Argon2 benchmark for decreasing parameters2017-08-12T17:32:23Zusername-removed-653601Fix Argon2 benchmark for decreasing parametersWhen we have measured time smaller than target time, we are decreasing
the parameters. Thus, we should first try to decrease t_cost and only
if that is not possible should we try to decrease m_cost instead. The
original logic was only va...When we have measured time smaller than target time, we are decreasing
the parameters. Thus, we should first try to decrease t_cost and only
if that is not possible should we try to decrease m_cost instead. The
original logic was only valid for the case where parameters are being
increased. Most notably this caused unusual parameter combinations for
iteration time < 250 ms.
In this commit we also factor out the now heavily nested parameter
update formula.https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/25Fix strncat usage2017-05-29T10:12:22Zusername-removed-653601Fix strncat usageThe 'strncat' function may write up to n + 1 bytes into destination, so
the 'n' parameter must be sizeof(dest) - strlen(dest) - 1. See [1] for
a nice explanation from US CERT.
[1] https://www.us-cert.gov/bsi/articles/knowledge/coding-pr...The 'strncat' function may write up to n + 1 bytes into destination, so
the 'n' parameter must be sizeof(dest) - strlen(dest) - 1. See [1] for
a nice explanation from US CERT.
[1] https://www.us-cert.gov/bsi/articles/knowledge/coding-practices/strncpy-and-strncatusername-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/24Don't use empty key when checking if cipher is usable2017-05-23T09:02:09Zusername-removed-1345292Don't use empty key when checking if cipher is usableSince kernel commit 28856a9e52c7cac712af6c143de04766617535dc (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/include/crypto/xts.h?id=28856a9e52c7cac712af6c143de04766617535dc),
aes-xts-plain64 cipher is unusable i...Since kernel commit 28856a9e52c7cac712af6c143de04766617535dc (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/include/crypto/xts.h?id=28856a9e52c7cac712af6c143de04766617535dc),
aes-xts-plain64 cipher is unusable in FIPS mode.
FIPS now requires AES XTS key to be composed of two non-equal parts.
The zero-filled empty_key as used in LUKS_check_cipher() doesn't
match the new criteria and is rejected by the kernel, resulting
in a failed cipher check.
Use a different dummy key.username-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/23Prevent double free with invalid verity partition.2017-05-02T07:05:45Zusername-removed-190189tobias@stoeckmann.orgPrevent double free with invalid verity partition.It is possible to trigger a double free with an invalid verity
partition. All it takes is an unknown hash algorithm, which makes it
a bit more likely than a completely broken partition header. But all
it takes is an error return value of...It is possible to trigger a double free with an invalid verity
partition. All it takes is an unknown hash algorithm, which makes it
a bit more likely than a completely broken partition header. But all
it takes is an error return value of VERITY_read_sb() or strdup().
If crypt_load fails before setting cd->type, crypt_free will handle
the union as if it was of type "none", which means it will call free()
for "active_name", a field which is only properly set up when the
type was actually "none".
In all other cases, "active_name" contains the first 4 or 8 bytes of
the actually used header structure. Fortunately it can be only a
pointer or NULL, so an attacker has no direct control of the value.
Nonetheless it can easily trigger a double free.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>username-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/22dracut-reencrypt: call "udevadm settle" once more2017-04-26T08:57:48Zusername-removed-1275695dracut-reencrypt: call "udevadm settle" once moreSomehow testing in qemu resulted sometimes in an endless loop.
Either the timing or the settle fixed the issue.
When the VM was in an endless loop, an strace showed, that the first 512
and 1024 of the crypt partition was read over and ov...Somehow testing in qemu resulted sometimes in an endless loop.
Either the timing or the settle fixed the issue.
When the VM was in an endless loop, an strace showed, that the first 512
and 1024 of the crypt partition was read over and over. Either it was
the udev blkid, or some device mapper udev rule.
Maybe the reencrypt tool opens and closes the device fd, where the close
triggers a udev blkid and causes the reencrypt tool to reread the device...
Anyhow.. with this settle the issue was not seen anymore.username-removed-113901username-removed-113901https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/21dracut-reencrypt: add UUID handling to rd.luks.reencrypt=2017-04-26T08:57:18Zusername-removed-1275695dracut-reencrypt: add UUID handling to rd.luks.reencrypt=This patch adds a udev rule, so that you can specify
rd.luks.reencrypt=<UUID> instead of rd.luks.reencrypt=<devname>
It also moves the job to the "settled" queue, which means, that it is
executed after udev has settled.This patch adds a udev rule, so that you can specify
rd.luks.reencrypt=<UUID> instead of rd.luks.reencrypt=<devname>
It also moves the job to the "settled" queue, which means, that it is
executed after udev has settled.username-removed-113901username-removed-113901https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/20dracut-reencrypt: add finished hook2017-04-26T08:56:21Zusername-removed-1275695dracut-reencrypt: add finished hookA finished hook prevents dracut-initqueue from exiting and lets it
finish the batched jobs. Without a "finished hook" and without
"root=<dev>" on the kernel command line, the reencrypt job would not be
executed.
Normally you want to ree...A finished hook prevents dracut-initqueue from exiting and lets it
finish the batched jobs. Without a "finished hook" and without
"root=<dev>" on the kernel command line, the reencrypt job would not be
executed.
Normally you want to reencrypt without a "root=<dev>" on the kernel
command and want to reboot after the reencrypt job is done.
This patch adds the missing "finished hook".username-removed-113901username-removed-113901https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/19Add wrapped-key cipher support to cryptsetup2017-07-09T14:27:10Zusername-removed-1252795Add wrapped-key cipher support to cryptsetupThis merge request introduces support for using wrapped-key ciphers for
disk encryption. Wrapped-key ciphers use a key, which itself is encrypted
(wrapped) by another key (the wrapping or key-encryption key).
Wrapped-key ciphers are ide...This merge request introduces support for using wrapped-key ciphers for
disk encryption. Wrapped-key ciphers use a key, which itself is encrypted
(wrapped) by another key (the wrapping or key-encryption key).
Wrapped-key ciphers are identified by its name, as specified by the
--cipher option.
The primary benefit of using wrapped keys rather than clear keys is that
the wrapped clear key is never exposed in the memory of the operating
system. With this you can provide end-to-end security systems where the
wrapping/key-encryption keys, for example, are maintained in an HSM. For
disk encryption, that means, the volume encryption key on the disk exists
in its wrapped form only.
**Summary of cryptsetup changes**
To support wrapped-key ciphers, a set of callback functions are introduced
that need to be implemented by wrapped-key cipher implementations. These
functions integrate seamlessly into cryptsetup to deal with the differences
that originate from using wrapped keys.
Also, the protected-AES (paes) wrapped-key cipher implementation is added
by using the previously introduced functions. The paes cipher implements
the AES encryption standard but uses wrapped keys. It is available on the
Linux on z Systems platform. To use the paes cipher to encrypt a disk,
specify '--cipher paes-cbc-plain64' or '--cipher paes-xts-plain64' with
luksFormat.
**Concepts and details on wrapped-key cipher support**
To perform cipher operations with wrapped keys, wrapped keys must be
be un-wrapped but for this, the wrapping key must be known.
Wrapping/key-encryption keys are typically stored in Hardware Security
Modules (HSMs) and do never leave the HSM. Wrapped-key cipher operations
thus happen inside the HSM. The data to be encrypted or decrypted and the
wrapped key is passed to the HSM. Within the HSM, the wrapped key is
un-wrapped (using the wrapping/key-encryption key) and, then, the crypto
operation is performed.
Note that wrapped keys typically have a different format and size than
a clear-key. They are mostly contained in a key-blob that might contain
additional meta-information. Because of this, wrapped-key ciphers have
certain constraints to the key material. For example, wrapped keys cannot
be simply generated as random byte strings, but must be generated within
an HSM. Also, wrapping/key-encryption keys might expire and become replaced
with new ones which requires that a wrapped key must be re-wrapped. (See
also patch 2/3).
As reference implementation and example, the protected-key-AES (paes)
wrapped-key cipher implementation is added.
The paes cipher is an in-kernel crypto module (kernel >v4.11) available
on the Linux on z Systems platform. It implements AES but uses wrapped
keys. The key that is passed to the paes cipher is a so-called 'secure key'.
Secure keys are wrapped keys that are generated by an HSM, in particular,
an IBM CryptoExpress card (in CCA coprocessor mode). The kernel also provides
the pkey ioctl interface to generate, convert, and validate secure keys.
The clear key used for the cipher operations is encrypted (wrapped) with
the master key of the HSM, forming a secure key.
To speed up secure key cipher operations, the paes cipher transforms secure
keys into so-called 'protected keys' as intermediate wrapped keys.
Protected keys are wrapped keys whereby the clear-key is wrapped by a
wrapping key stored in hidden memory accessible only by z Systems firmware.
Cipher operations with protected keys are performed on a co-processor
inside the CPU and are therefore much faster than secure key operations
which require an I/O to the HSM for each cipher operation.
With the help of a CryptoExpress card a secure key can securely be transformed
into a protected key. Note, the wrapping keys inside the z Systems firmware
are (re)generated with every system boot. Therefore protected keys are
volatile and must be regenerated from the (non-volatile) secure keys whenever
they are used for the first time after an system boot (or image migration).
Thanks and kind regards,
Ingo, Hendrikusername-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/18Add read_blockwise_offset function for s390x and O_DIRECT reading2017-04-04T14:25:11Zusername-removed-36141Add read_blockwise_offset function for s390x and O_DIRECT readingAn EINVAL error can be thrown when attempting to read a file with
O_DIRECT on some systems. While testing on a s390x system using
TCRYPT_HDR_HIDDEN_OFFSET_OLD the file read was failing since the
offset is not aligned properly.
read_bloc...An EINVAL error can be thrown when attempting to read a file with
O_DIRECT on some systems. While testing on a s390x system using
TCRYPT_HDR_HIDDEN_OFFSET_OLD the file read was failing since the
offset is not aligned properly.
read_blockwise_offset is just a simple wrapper to call read_blockwise
first and then attempt to read again with a modified offset that is
aligned.
---
I did this fix a long time ago (11/2014), so forgive me if I've forgotten some details.
One interesting detail was when opening without O_DIRECT the reads in the tests ran succeeded.
From one of my notes:
Had an idea that with O_DIRECT it was attempting to read an entire physical block size of 4096 bytes. There are only 1532 (sic) bytes left until the end of the file with version 2 and 3 hidden headers. Wrote a new test to seek to 4096 bytes before the end of the file and was able to read the file with the O_DIRECT flag. It seems to be that on s390x if there isn't enough space to read left on the file the read will fail instead of returning the rest of the file. I'm not sure why this succeeds on other architectures though.
*I typo'd 1532, suppose to be 1536*
I was told something in this message implies that reads on s390x should be aligned to 4096 bytes:
http://lists.gnu.org/archive/html/qemu-devel/2012-12/msg00921.html
This mentions one should use the BLKSSZGET ioctrl to get the proper block size rather than hardcoding 512 bytes.
https://www.quora.com/Why-does-O_DIRECT-require-I-O-to-be-512-byte-alignedusername-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/17Add hashMode parameter in CryptSetup_luksFormat()2017-03-01T12:36:40Zusername-removed-560195Add hashMode parameter in CryptSetup_luksFormat()We now can select the hash mode in pycryptsetup module when formatting device to enable LUKS.We now can select the hash mode in pycryptsetup module when formatting device to enable LUKS.username-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/16support PIM parameter for VeraCrypt compatible devices2017-03-02T08:24:32Zusername-removed-1089654support PIM parameter for VeraCrypt compatible devicesThis patch adds the --veracrypt-pim=INT command-line parameter to support
specification of a Personal Iteration Multiplier, which affects the number
of iterations for key derivation from the entered password.
Also the main manpage is up...This patch adds the --veracrypt-pim=INT command-line parameter to support
specification of a Personal Iteration Multiplier, which affects the number
of iterations for key derivation from the entered password.
Also the main manpage is updated.
Closes #307username-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/14Enhance openssl 1.1.0 compatibility2017-01-05T08:14:32Zusername-removed-487426Enhance openssl 1.1.0 compatibility- Don't use deprecated version API
- Skip openssl initialization, openssl handles this internally
This prevents build failures when openssl 1.1.0 is built with --api=1.1 or
compatibility mode is not enabled.
X-Gentoo-Bug: 604698
X-Gent...- Don't use deprecated version API
- Skip openssl initialization, openssl handles this internally
This prevents build failures when openssl 1.1.0 is built with --api=1.1 or
compatibility mode is not enabled.
X-Gentoo-Bug: 604698
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=604698username-removed-113594username-removed-113594https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/10Fixed veritysetup bug with hash offsets bigger than 2gb.2016-10-22T07:32:11Zusername-removed-797181Fixed veritysetup bug with hash offsets bigger than 2gb.https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/9Avoid integer overflows during memory allocation.2016-07-02T19:10:14Zusername-removed-190189tobias@stoeckmann.orgAvoid integer overflows during memory allocation.It is possible to overflow integers during memory allocation with
insanely large "key bytes" specified in a LUKS header.
Although it could be argued to properly validate LUKS headers while
parsing them, it's still a good idea to fix...It is possible to overflow integers during memory allocation with
insanely large "key bytes" specified in a LUKS header.
Although it could be argued to properly validate LUKS headers while
parsing them, it's still a good idea to fix any form of possible
overflow attacks against cryptsetup in these allocation functions.https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/8Avoid buffer overflow in uuid_or_device.2016-07-02T18:49:27Zusername-removed-190189tobias@stoeckmann.orgAvoid buffer overflow in uuid_or_device.The function uuid_or_device is prone to a buffer overflow if a very long
spec has been defined. The range check happens against PATH_MAX, with
i being set to 5 (due to "UUID=" offset of spec), but "/dev/disk/by-uuid"
has been already ...The function uuid_or_device is prone to a buffer overflow if a very long
spec has been defined. The range check happens against PATH_MAX, with
i being set to 5 (due to "UUID=" offset of spec), but "/dev/disk/by-uuid"
has been already written into device.
The difference between "/dev/disk/by-uuid" and "UUID=" is 13, therefore
the correct range check must happen against PATH_MAX - 13.
@@ -204,7 +204,7 @@ const char *uuid_or_device(const char *spec)
strcpy(device, "/dev/disk/by-uuid/");https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/5Fix device_block_size_fd and fix EINVAL for read when using DIRECT_IO2016-03-23T13:26:31Zusername-removed-456172Fix device_block_size_fd and fix EINVAL for read when using DIRECT_IOThis patch is for issue https://gitlab.com/cryptsetup/cryptsetup/issues/287
This patch addresses:
- fix device_block_size_fd to return block size correctly incase of files.
Also in case of 4k sector size, when opening files in O...This patch is for issue https://gitlab.com/cryptsetup/cryptsetup/issues/287
This patch addresses:
- fix device_block_size_fd to return block size correctly incase of files.
Also in case of 4k sector size, when opening files in O_DIRECT mode, proceeded by lseek of value which
is not aligned to 4k size and read fails with EINVAL.
Adding a viable patch which does:
- In case of block device, check if lseek value is multiple of sector size ( using ioctl ) , else unset device->o_direct
- In case of files, lseek and perform a device_read_test to make sure direct_io works, else unset device->o_direct
Signed-off-by: Athira Rajeev<atrajeev@linux.vnet.ibm.com>https://staging.gitlab.com/cryptsetup/cryptsetup/-/merge_requests/4add algo-cipher field when unlocking luks2 volume2017-01-02T12:34:07Zusername-removed-368720add algo-cipher field when unlocking luks2 volume
```
Output of currest upstream is below when the volume is "Wrongly" unlocked:
dmsetup table luks2
0 36864 crypt aes 0000000000000000000000000000000000000000000000000000000000000000 0 7:0 4096
[root@ink mtz]# /usr/local/sbin/...
```
Output of currest upstream is below when the volume is "Wrongly" unlocked:
dmsetup table luks2
0 36864 crypt aes 0000000000000000000000000000000000000000000000000000000000000000 0 7:0 4096
[root@ink mtz]# /usr/local/sbin/cryptsetup status luks2
/dev/mapper/luks2 is active.
type: LUKS2
cipher: aes-cbc-plain
keysize: 256 bits
device: /dev/loop0
loop: /home/mtz/luks2.img
offset: 4096 sectors
size: 36864 sectors
mode: read/write
Notice "dmsetup table" command does not show an entry for cipher in use and "cryptsetup status" reports wrong cipher.
This pull request corrects this and produces below output when the volume is "correctly" unlocked:
[root@ink mtz]# dmsetup table luks2
0 36864 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 7:0 4096
[root@ink mtz]# /usr/local/sbin/cryptsetup status luks2
/dev/mapper/luks2 is active.
type: LUKS2
cipher: aes-xts-plain64
keysize: 256 bits
device: /dev/loop0
loop: /home/mtz/luks2.img
offset: 4096 sectors
size: 36864 sectors
mode: read/write
[root@ink mtz]#
luksDump for the luks2 volume unlocked above is below:
[root@ink mtz]#
[root@ink mtz]# /usr/local/sbin/cryptsetup luksDump luks2.img
LUKS header information
Version: 2
Epoch: 4
Metadata area: 15872 bytes
UUID: e43c817c-057a-45f2-bec4-adcac33373c8
Label: (no label)
Subsystem: (no subsystem)
Data segments:
0: crypt
offset: 2097152 [bytes]
length: (whole device)
cipher: aes-xts-plain64
block: 512 [bytes]
Keyslots:
0: luks2 (active)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Iterations: 602
Memory: 1024
Threads: 4
Salt: 83 2a 97 e8 dc f6 4c 95 aa bd fc e1 63 73 c5 56
42 10 ba e1 0d 0b 4e 53 89 24 d3 ab 97 12 61 8a
Area: 0
Offset: 32768 [bytes]
Length: 131072 [bytes]
Digest ID: 0
1: luks2 (active)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Iterations: 602
Memory: 1024
Threads: 4
Salt: 25 16 bd 09 f1 b3 3e 40 fc 96 40 ca 47 68 6a 76
0b 86 35 19 c2 e1 5f e6 d9 ca 0d be ef 70 89 57
Area: 1
Offset: 163840 [bytes]
Length: 131072 [bytes]
Digest ID: 0
2: luks2 (inactive)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Area: 2
Offset: 294912 [bytes]
Length: 131072 [bytes]
Digest ID: 0
3: luks2 (inactive)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Area: 3
Offset: 425984 [bytes]
Length: 131072 [bytes]
Digest ID: 0
4: luks2 (inactive)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Area: 4
Offset: 557056 [bytes]
Length: 131072 [bytes]
Digest ID: 0
5: luks2 (inactive)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Area: 5
Offset: 688128 [bytes]
Length: 131072 [bytes]
Digest ID: 0
6: luks2 (inactive)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Area: 6
Offset: 819200 [bytes]
Length: 131072 [bytes]
Digest ID: 0
7: luks2 (inactive)
Key: 256 bits
Priority: normal
Cipher: aes-xts-plain64
PBKDF: argon2
Hash: sha256
Stripes: 4000
Area: 7
Offset: 950272 [bytes]
Length: 131072 [bytes]
Digest ID: 0
Digests:
0: luks1
Hash: sha256
Iterations: 1000
Salt: 67 ad e9 0d e1 a6 a4 93 3d 5c f1 c8 1d a7 de 7d
db 18 ef 6e e3 0f 4a 77 bf 00 bc 7f 75 dd 28 9e
Digest: c8 b8 f6 d3 1a ae ad bd a5 0f f2 26 0f bc b8 c4
```