From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sun, 2 Feb 2020 17:46:16 +0100 (CET) Received: by mail-wr1-x429.google.com with SMTP id y11so14891926wrt.6 for ; Sun, 02 Feb 2020 08:46:16 -0800 (PST) Received: from [192.168.2.27] (39.35.broadband4.iol.cz. [85.71.35.39]) by smtp.gmail.com with ESMTPSA id e17sm8623481wrn.62.2020.02.02.08.46.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 Feb 2020 08:46:14 -0800 (PST) From: Milan Broz Message-ID: <7ed225e8-e105-0dab-cc45-2af52f3a6a2c@gmail.com> Date: Sun, 2 Feb 2020 17:46:13 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q7rUs5eW0fZQ2PC3ygwlDmTk5AGGnqASr" Subject: [dm-crypt] [ANNOUNCE] cryptsetup 2.3.0 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q7rUs5eW0fZQ2PC3ygwlDmTk5AGGnqASr Content-Type: multipart/mixed; boundary="MDTY7CmOcKJWmoHkIgAl1yEDVBYwayJQp" --MDTY7CmOcKJWmoHkIgAl1yEDVBYwayJQp Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable The cryptsetup 2.3.0 stable release is available at https://gitlab.com/cryptsetup/cryptsetup Please note that release packages are located on kernel.org https://www.kernel.org/pub/linux/utils/cryptsetup/v2.3/ Feedback and bug reports are welcomed. Cryptsetup 2.3.0 Release Notes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Stable release with new experimental features and bug fixes. Cryptsetup 2.3 version introduces support for BitLocker-compatible devices (BITLK format). This format is used in Windows systems, and in combination with a filesystem driver, cryptsetup now provides native read-write access to BitLocker Full Disk Encryption devices. The BITLK implementation is based on publicly available information and it is an independent and opensource implementation that allows to access this proprietary disk encryption. Changes since version 2.2.2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~ * BITLK (Windows BitLocker compatible) device access BITLK userspace implementation is based on the master thesis and code provided by Vojtech Trefny. Also, thanks to other opensource projects like libbde (that provide alternative approach to decode this format) we were able to verify cryptsetup implementation. NOTE: Support for the BITLK device is EXPERIMENTAL and will require a lot of testing. If you get some error message (mainly unsupported metadata in the on-disk header), please help us by submitting an issue to cryptsetup project, so we can fix it. Thank you! Cryptsetup supports BITLK activation through passphrase or recovery passphrase for existing devices (BitLocker and Bitlocker to Go). Activation through TPM, SmartCard, or any other key protector is not supported. And in some situations, mainly for TPM bind to some PCR registers, it could be even impossible on Linux in the future. All metadata (key protectors) are handled read-only, cryptsetup cannot create or modify them. Except for old devices (created in old Vista systems), all format variants should be recognized. Data devices can be activated read-write (followed by mounting through the proper filesystem driver). To access filesystem on the decrypted de= vice you need properly installed driver (vfat, NTFS or exFAT). Foe AES-XTS, activation is supported on all recent Linux kernels. For older AES-CBC encryption, Linux Kernel version 5.3 is required (support for special IV variant); for AES-CBC with Elephant diffuser, Linux Kernel 5.6 is required. Please note that CBC variants are legacy, and we provide it only for backward compatibility (to be able to access old drives). Cryptsetup command now supports the new "bitlk" format and implement du= mp, open, status, and close actions. To activate a BITLK device, use # cryptsetup open --type bitlk or with alias # cryptsetup bitlkOpen Then with properly installed fs driver (usually NTFS, vfat or exFAT), you can mount the plaintext device /dev/mapper device as a common= filesystem. To print metadata information about BITLK device, use # crypotsetup bitlkDump To print information about the active device, use # cryptsetup status Example (activation of disk image): ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Recent blkid recognizes BitLocker device,just to verity # blkid bitlocker_xts_ntfs.img bitlocker_xts_ntfs.img: TYPE=3D"BitLocker" # Print visible metadata information (on-disk, form the image) # cryptsetup bitlkDump bitlocker_xts_ntfs.img Info for BITLK device bitlocker_xts_ntfs.img. Version: 2 GUID: ... Created: Wed Oct 23 17:38:15 2019 Description: DESKTOP-xxxxxxx E: 23.10.2019 Cipher name: aes Cipher mode: xts-plain64 Cipher key: 128 bits Keyslots: 0: VMK GUID: ... Protection: VMK protected with passphrase Salt: ... Key data size: 44 [bytes] 1: VMK GUID: ... Protection: VMK protected with recovery passphrase Salt: ... Key data size: 44 [bytes] 2: FVEK Key data size: 44 [bytes] # Activation (recovery passphrase works the same as password) # cryptsetup bitlkOpen bitlocker_xts_ntfs.img test -v Enter passphrase for bitlocker_xts_ntfs.img: Command successful. # Information about the active device # cryptsetup status test /dev/mapper/test is active. type: BITLK cipher: aes-xts-plain64 keysize: 128 bits ... # Plaintext device should now contain decrypted NTFS filesystem # blkid /dev/mapper/test /dev/mapper/test: UUID=3D"..." TYPE=3D"ntfs" # And can be mounted # mount /dev/mapper/test /mnt/tst # Deactivation # umount /mnt/tst # cryptsetup close test * Veritysetup now supports activation with additional PKCS7 signature of root hash through --root-hash-signature option. The signature uses an in-kernel trusted key to validate the signature of the root hash during activation. This option requires Linux kernel 5.4 with DM_VERITY_VERIFY_ROOTHASH_SIG option. Verity devices activated with signature now has a special flag (with signature) active in device status (veritysetup status ). Usage: # veritysetup open name \ --root-hash-signature=3D * Integritysetup now calculates hash integrity size according to algorith= m instead of requiring an explicit tag size. Previously, when integritysetup formats a device with hash or HMAC integrity checksums, it required explicitly tag size entry from a user (or used default value). This led to confusion and unexpected shortened tag sizes. Now, libcryptsetup calculates tag size according to real hash output. Tag size can also be specified, then it warns if these values differ. * Integritysetup now supports fixed padding for dm-integrity devices. There was an in-kernel bug that wasted a lot of space when using metada= ta areas for integrity-protected devices if a larger sector size than 512 bytes was used. This problem affects both stand-alone dm-integrity and also LUKS2 with authenticated encryption and larger sector size. The new extension to dm-integrity superblock is needed, so devices with the new optimal padding cannot be activated on older systems. Integritysetup/Cryptsetup will use new padding automatically if it detects the proper kernel. To create a compatible device with the old padding, use --integrity-legacy-padding option. * A lot of fixes to online LUKS2 reecryption. * Add crypt_resume_by_volume_key() function to libcryptsetup. If a user has a volume key available, the LUKS device can be resumed directly using the provided volume key. No keyslot derivation is needed, only the key digest is checked. * Implement active device suspend info. Add CRYPT_ACTIVATE_SUSPENDED bit to crypt_get_active_device() flags that informs the caller that device is suspended (luksSuspend). * Allow --test-passphrase for a detached header. Before this fix, we required a data device specified on the command line even though it was not necessary for the passphrase check. * Allow --key-file option in legacy offline encryption. The option was ignored for LUKS1 encryption initialization. * Export memory safe functions. To make developing of some extensions simpler, we now export functions to handle memory with proper wipe on deallocation. * Fail crypt_keyslot_get_pbkdf for inactive LUKS1 keyslot. Libcryptsetup API extensions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The libcryptsetup API is backward compatible for existing symbols. New symbols crypt_set_compatibility crypt_get_compatibility; crypt_resume_by_volume_key; crypt_activate_by_signed_key; crypt_safe_alloc; crypt_safe_realloc; crypt_safe_free; crypt_safe_memzero; New defines introduced : CRYPT_BITLK "BITLK" - BITLK (BitLocker-compatible mode CRYPT_COMPAT_LEGACY_INTEGRITY_PADDING - dm-integrity legacy padding CRYPT_VERITY_ROOT_HASH_SIGNATURE - dm-verity root hash signature CRYPT_ACTIVATE_SUSPENDED - device suspended info flag --MDTY7CmOcKJWmoHkIgAl1yEDVBYwayJQp-- --q7rUs5eW0fZQ2PC3ygwlDmTk5AGGnqASr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKikYJD/eRmSNBob52bBXe9k+mPwFAl42/NUACgkQ2bBXe9k+ mPxa7w//c8SAsVqfWE6Zi1vAGueFViQYqSHAuOHV7sp7ql77mc3TK+ynf3dauzmS bJPKRhv0YsLiTjA/dX2eHmoTGoOd2OGAYy5r4C9TYfTb92bGanUcGs0cfVmptlBi F7C5WbaXdLQyNK06jtqHzE7n24G2bCD9/0ZUP/gFeUbL838Z8TGU52Kyuti7F2Lj 66aE6x/yP2Q8S3RfCJKDW4Lvig6WCDn3ynYxXkp52Io/DrAEV7pqUMn8N8h+4PEc 1lw9uwEFctxt2IL/F6j36pZHCHK8jxTfTQoFWG9ysSy5LgR6L7JK84FlCl6v9Zoc 3atpce7FsN1Clwr1X8aHTQZMgBftkkhW0wRozMu1XWAEQ+9fQoKszhddRoyIqaiA lpPdvvU7s8wsnxw/eewEX3mDpWpV1Pm+kYcwTpefgLhXXvY9OJTCxuEDrmxkkFf9 dvsyOWNDWNPhantnQEijT5zJW14xzwu2cjNTZha1IsnLmreBJ6tQHiGw76BdKIUg yKWsWw5vP+r7DAzwjV9GwvSjrBAZwca1FUEpLhHo7OiwBlQGdObpHoges41SeFLk lUQ+NRSnSGlmyJBqpi1T4cGBS4pJ3J/W99iso2nKjFsE5GbNydVKBD65Y+JHp7/+ Z/W90tw0kZ7RBFbzDjhf06OjWs6AishTg+FD+mVfYp7Eh2tWgZk= =GLlx -----END PGP SIGNATURE----- --q7rUs5eW0fZQ2PC3ygwlDmTk5AGGnqASr--