From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 10CF81382C5 for ; Sun, 7 Jun 2020 16:44:35 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 76D22E0922; Sun, 7 Jun 2020 16:44:27 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D4CE9E08AA for ; Sun, 7 Jun 2020 16:44:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1591548254; bh=8ZaTH0SWQMXa1LPQvTzmmLcmS7umZKQiLa0vS01HK9Y=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=awM8r1GLX+1pJCgQGR5p8lyn2Nb2mN0w4ptftPxhl9lhTZ4O5TL2SWZRBIpnBlhPf tA+0nso5CyFXvlXxHOWSqlXFkRYco9fIlHIjmyRa/lA7rIzDf4TtgSGInkV9I48l5C pxr/Uvl5MPWulemhGlM6NNZCHjbZGaj+CMgpjDhU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from kern ([92.117.40.43]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N1Obb-1iwTIg0g15-012nIr for ; Sat, 06 Jun 2020 17:07:13 +0200 Date: Sat, 6 Jun 2020 17:07:11 +0200 From: Frank Steinmetzger To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Encrypting a hard drive's data. Best method. Message-ID: <20200606150711.GA274766@kern> Mail-Followup-To: gentoo-user@lists.gentoo.org References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: User-Agent: Mutt 1.14.1; VIM - Vi IMproved 8.2 X-Provags-ID: V03:K1:ylnjEiR6arnMZ+QRbYmAj4Ak0U+7YSc5tmkB80KCnXszgVwh3S/ 8wX3xc77vYJjD4hPytL0CYZEUrMBp4n5HSMKQi3K+DwDsonExxTBe2CFHZ/9Fjt6fVRR7t7 Sth3WUYQMF9j6AStqHyTiHeT6nYfKj7PKZZoTq3E12zSmKXO2zAjmby8waz6mPeCkEWjfCu vHN7V+aFF+Ql35l3txDkA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:P+brUiMNYJI=:V/TS8PrprSa+v/L+BKGG4S JDM9r0xtFpmrw8oysHYNl4pakdWYnbHKR8yp2maic+Ua50AHFefF1FytPOnoqlw5VWMqIlDSg srd0g5p44PQSrxlV0wFgHF0wByH75uDy9l5Znrz8HJBLinx/5VEh03uB+u0neVWBRxAgYbPnY Kq3b+d1fvOZCYDWW9hvubOONBr1dl6BK+FLCypESMpY7qp4ssvEKNLe9ZXx+ziOXatIo7DEgt 8Gjva5h+iZZKApOBZvVrHKkG1u+8q3nv0rODeLh0eHLtvF7CJyJ5/8ZRylpEj9l88a3Rhc/fU P9ZrMCze7S770RLPg8GPRIbhQmpxEeO/BCuEV0JnjHutY3gFTNUL2hdaHNQBXcWY+iooUCism GR7BS2kr0QCSF/fsJFvPRlCSNfwMQmPSRQa9ml8Z/4VXFg99rTEpiC69TMqQdygRR+VQeqKxk ci+D51LGxgdLGr8IZiSiCSZYdG9EJf/YnV1fol+rPrrsE+wZX2Y5G9YCJ04k3Wgqx05J6MSl3 C4ocZyoJDyTb+VC67N5vqrdmI2XAHmKQ5nGVJoHnURUNyLG1E2H0FauNCKWemT66T/02xJztq 37Oj40Lcn/9+MPnhCas0MwS4lAZvqP1MjRjtDYPpLkRQiKtM+OU567YkX4qjxAbvUCHTCQBJ/ lrCt8Ec5BXbVaOwS0UyzzHFGDhcNMGVV1blabeceKYswVtGRlUayI1umN/gwUFdygeWBDWVKB t9hCCqsgBSY8aOJQwRIeQwe1Scm1Xp9jPuQqMA4mRl60bNfOERWt4svH0DE1KLvfnD5mbGwyI IDkwdgfqGv/QhhvyCxVViNlehZ2fBYuwIFOkRHr+qlE8Ral0NE/wIpcftRtl2K8tNNdMRYyVT tCYVUOQo6+jRpknpqr/jcWuA68grSx/AlJCWw8RW0m4ZwBxl8pdSXyKKKobJnoT8LNwn031CG hM6qBnXv11ZGqaqFME8jUkUV5H6NFsCAabn0+yiCrAzNMdTDIrdX6SdVI30uTOpb8Zv+oA6qp eputpxrOif+QmyGHJyo9K/gmPH8qkntWWAG3oKwEzCCe3fnTvgrZhx6wDrd4nnPetol+3dMLb ZPQ3It3TZaRyRKkRcN7YNgfIQL9MTqC67x1Ya0/c7sZa0kckFsaaAEwoy/bUxd8shFrF7qTf1 9VDdsGub73r5W/WGwgPQdfO+qlvIwjry+fkAUCgP9qFmMUL2pLYeDl2OsCQR2wvSdXB0zCZh2 Wt4nFyEdZyuvnKc5F X-Archives-Salt: 3b410b0d-c969-4e28-a608-ab8bbe39e495 X-Archives-Hash: 2505e70606e1992c3a742085d8ab83aa --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 05, 2020 at 11:37:23PM -0500, Dale wrote: > Howdy, >=20 > I think I got a old 3TB hard drive to work.=C2=A0 After dd'ing it, redoing > partitions and such, it seems to be working.=C2=A0 Right now, I'm copying= a > bunch of data to it to see how it holds up.=C2=A0 Oh, it's a PMR drive to= o.=C2=A0 > lol=C2=A0 Once I'm pretty sure it is alive and working well, I want to pl= ay > with encryption.=C2=A0 At some point, I plan to encrypt /home.=C2=A0 I fo= und a bit > of info with startpage but some is dated.=C2=A0 This is one link that see= ms > to be from this year, at least updated this year.=C2=A0 Encryption is a means to protect against adversaries, but in my case I mostly want to protect from incidental access. My top =E2=80=9Cuse=E2=80=9D= cases: - I need to send in a broken disk for service/replacement - $DEVICE is stolen and I dont=E2=80=99t want the thief to access my person= al stuff - the device needs to be serviced, but has its storage soldered on - protect from recovery on flash storage I=E2=80=99ve been running full-disk encryption with LUKS/LVM for some years= now on my laptop=E2=80=99s SSD. I used Sakaki=E2=80=99s scripts to set up the kern= el and initrd. The encryption password is entered during the boot process while still in the initrd phase. I don=E2=80=99t know of the current status of Sakaki=E2= =80=99s stuff though (I must admit I moved away from Gentoo because portage took to much time on the laptop). On my main PC I used to have ~ on a hard disk and / on an SSD. So I left / unencrypted and symlinked sensitive files such as wpa_supplicant.conf and database files onto a directory beneath /home. Since decryption is done early at boot, there is no race condition. By now I upgraded the SSD and have both / and ~ on it, but I kept the scheme out of laziness. A week ago I got me and myself a used Surface Go (a little X86 tablet) which only has a small SSD soldered onto the board. There is no way to access or replace it. I didn=E2=80=99t want to use the same approach as with the lapt= op, because I wanted to be able to boot without a keyboard. This meant that PW entry at early boot was no option because there is no touch support at this stage. So I researched a little towards decryption at login. Ext4-internal encryption was a strong contender, because it allowed me to decrypt ~ on login, while still using a shared partitions for / and ~, which would give me more flexibility on the constrained SSD. It also encrypts filenames, but not access times (which I was OK with). Eventually though, I decided to go for more encapsulation and put ~ on a separate partition again. I set it up with LUKS and auto-mount it on login with pam_mount. On a performance not: the Surface Go has an NVME SSD and hdparm -t varies wildly between 220 and 640 MB/s. OTOH, cryptsetup benchark resulted in 1330 MiB/s for aes-cbc with a 128 bit key. Aes-xts was slower, but once I disabled all kernel mitigations=C2=B9, its throughput went up by more than = 40 % and also reached 1300 MiB/s. And this is for the meagre Pentium Gold processor. So no worries in that department. =C2=B9 Many of those vulnerabilities are about violating memory boundaries,= which is most relevant for server operators and securing their users from each other. Thus, I don=E2=80=99t care about those on my personal machines and r= ather have the original performance. Exploits need to get *on* my machines first before they can snoop in my memory. --=20 Gru=C3=9F | Greetings | Qapla=E2=80=99 Please do not share anything from, with or about me on any social network. I hate being bi-polar. It=E2=80=99s fantastic! --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEVbE9o2D2lE5fhoVsizG+tUDUMMoFAl7bsR0ACgkQizG+tUDU MMoWyw/9F4FMwWmDbzfjg1V8ziY43BjOMs/NSa5xzJXyN6HgBTw+NJ6Z3QJp+d9y U+81QZ5gCgE9oXyczzXoFRq66M+zThUhBjqumapgQ/Zq/cPhV/DDNqkErcxFU7Jh YKkJEnqXXKoM4nSjXuntCRfvPrLJ3opzwt78PQuNBPHARkstkIhSZVvTldQ24BRv sjvySv2AYggmw8PDq2Ln2ZRwdxAuXpWL6t5+CcJhKwQipVcvQ0KUp5UvzDzPOXaH rNlYcC3uCfq9nSHaW+zCdcJz3tGA6B7DIEUZESajbVpghz7LlOExzZ5mxZlzyGFW iYbnfLUZ9VbxG/pATFjvVESicWWDKQQ9v9IYXPzCHDjg0jJrBT+JTi/m4yeqpJCD iUGQK3QSyX4A/he+vqGAW2vXhJ2FAP1B8FqwQbpNcYeaiwsir/bUpNLlehw46Ipq eCY0QHQNPgY9a7E89A52WTUv36PKY27BUjPHR1xEpA2/j21Wc5TdsagmXNKIFHCo /8xEVtrM2JhtVi+x2A/ryihKo4ZhIN6BgFwEsDbjcfbeIIgqN1Tn35N2bv+0o5fE a5nVLnEKpq+WXlWq38VTfOCi0FHoHcmt9K5r24TBGkhkQrmZOocAB6pPNXu8ecm0 d+XC4cYWVOBp0T8AeJQeTwOk7dlIHpA1vgoh3dZ1dWiW1mDx8AI= =SPjO -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--