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 47DB51382C5 for ; Sat, 6 Jun 2020 18:52:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CEACEE0A7C; Sat, 6 Jun 2020 18:52:11 +0000 (UTC) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (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 7E8DBE09F3 for ; Sat, 6 Jun 2020 18:52:11 +0000 (UTC) Received: by mail-ej1-f50.google.com with SMTP id gl26so13768077ejb.11 for ; Sat, 06 Jun 2020 11:52:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FTbVJM93MeICCXMlAtGBDPnGoPzPTk1myxOijOU5MIk=; b=dZ5I2bdYkW0crQyikWOHaaQIxUIOHkXmaVcop9djgWCasuPApdy5c8/iWNt+HSg8ux f06e+QlRAKTUN6wUZPkjHClMq9T81u54P4IHVB+WRNkTvsj1BFkjOkUpsPWd0OzFR67y y9Bp0zhlRUqdIpHYWow6bhHfv2yJwX0innbjVwWoEW28aNVxjXYp8+EJZk9FMIMyIHfL LEIaZOQDXBecWq123//92LM9g2uMNoeUG8Huovf0VZ+gy9hVC0PFPKSo6TUn7VZwPKE3 cBG2y7gh8tF/LBBw2ev/gujiikWDCQ7g4CPwOE/MbtWD7Ysk0olfTs1KWyarRAMjXkxC uE9w== X-Gm-Message-State: AOAM532NfRlhrCdtmoOSXt0RLzBPohR4RnS1g6Cz9x2Va7k6gEuh9Oab jA7+GhCD1z9pqFJ6m5iTqLOycQHKbIsInKdBcSCNHg== X-Google-Smtp-Source: ABdhPJzljqSg+508JFKhCOUHuMr/sSqH8dspfoxCcL+pujAUi5wJU9/9OM1QeVyr8WI+7dCU/d5Zr831vwqpogWG6OU= X-Received: by 2002:a17:906:784c:: with SMTP id p12mr14109188ejm.123.1591469529862; Sat, 06 Jun 2020 11:52:09 -0700 (PDT) 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 References: <7e55092b-1914-da09-cb33-25aea63d2b22@gmail.com> In-Reply-To: <7e55092b-1914-da09-cb33-25aea63d2b22@gmail.com> From: Rich Freeman Date: Sat, 6 Jun 2020 14:51:59 -0400 Message-ID: Subject: Re: [gentoo-user] Encrypting a hard drive's data. Best method. To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 0a48baec-3482-4669-8f69-416937b2d078 X-Archives-Hash: 953b2931d504331a94b67a2bcd5f47df On Sat, Jun 6, 2020 at 10:07 AM Victor Ivanov wrote: > > The problem here is that a leaked header immediately means a compromised > volume. An adversary who gets hold of the header can now spend as much > time as they would like to brute force a password (depending on password > strength) and derive the encryption key. Or if they have an (older) copy > of the header with a leaked password before it was changed they can get > hold of the encryption key with virtually no effort at all by using said > password. The only solution to a compromised header is full > re-encryption. Even having a rolling password won't change that. If you're talking about the drive header that is actually written to disk, it is as secure as the entire drive is, since the drive contains the header. The whole point of full-disk encryption is to keep the contents of the disk secure even if you lose physical possession of the disk. If the password can be brute-forced then the encryption is worthless. Sure, if the attacker has a copy of the header they can spend as much time as they wish brute-forcing it. However, the same is true if they have the entire disk, and that is precisely the scenario we're trying to guard against. If you're using LUKS the security of the system is only as secure as your password(s). LUKS uses a random key to encrypt the drive, and it applies many rounds of encryption to your password to protect the session key. That will greatly slow down a brute force attack. However, if your encryption key is "12345" then a brute force attack is likely to succeed. -- Rich