From owner-freebsd-current@freebsd.org Tue Oct 20 09:21:36 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B3A93A1A685 for ; Tue, 20 Oct 2015 09:21:36 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46331BD8 for ; Tue, 20 Oct 2015 09:21:36 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: by wicll6 with SMTP id ll6so18697876wic.1 for ; Tue, 20 Oct 2015 02:21:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:message-id:to:subject:cc:reply-to :in-reply-to; bh=EwiSd7oNOCRbnYoQBpNSkrwbKBeSxb7uiiGbigKe4h0=; b=JxoX4/heSuYsQ4jxSx/T6vcfThebEkqrFJ+FjpJ62x7gSV3yKGUJYfpMnumx1vwGEm nXlOsxBUpIc5x2SQ7RAu5tJBaXbz+mbLSpAvCBHGcEqyszpr9aUWciTrN+ZsthKW60tr EKbZToDyU6LdOgDCZTceuhP6ZOgYr0GZcMgC9oqVCJc2CqflBbc/CeX+cALBIWUh+Vyc QFXgKLsNuuS9L4vxjzkFDnCQEkT0fbo1Z5joF/jO+/Gc7M523AF7Ft8JZQJAnkMHdw9k hqjB3u4/PSkjaIU7uz1Q99ayCgi5zy/MIwxFTFgsJSMnZMBN0d8rpl3Zu9Xv3K9981HL i5lw== X-Gm-Message-State: ALoCoQmW06pbLQyC+bNqG0QTZ05p1+AstFkq6HOZZjJ+63HoDtnEpYJjNibk5drRMtXJ8iYMaVbo X-Received: by 10.180.87.71 with SMTP id v7mr18070517wiz.77.1445332894258; Tue, 20 Oct 2015 02:21:34 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (mech-as222.men.bris.ac.uk. [137.222.170.4]) by smtp.gmail.com with ESMTPSA id ee5sm2598688wjd.17.2015.10.20.02.21.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2015 02:21:33 -0700 (PDT) Received: from mech-as222.men.bris.ac.uk (localhost [127.0.0.1]) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2) with ESMTP id t9K9LWGV005536; Tue, 20 Oct 2015 10:21:32 +0100 (BST) (envelope-from mexas@mech-as222.men.bris.ac.uk) Received: (from mexas@localhost) by mech-as222.men.bris.ac.uk (8.15.2/8.15.2/Submit) id t9K9LWrD005535; Tue, 20 Oct 2015 10:21:32 +0100 (BST) (envelope-from mexas) Date: Tue, 20 Oct 2015 10:21:32 +0100 (BST) From: Anton Shterenlikht Message-Id: <201510200921.t9K9LWrD005535@mech-as222.men.bris.ac.uk> To: mexas@bris.ac.uk, phk@phk.freebsd.dk Subject: Re: Depreciate and remove gbde Cc: freebsd-current@freebsd.org, rwmaillists@googlemail.com, yaneurabeya@gmail.com Reply-To: mexas@bris.ac.uk In-Reply-To: <96318.1445331396@critter.freebsd.dk> X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 09:21:36 -0000 >From phk@phk.freebsd.dk Tue Oct 20 10:08:55 2015 > >>Am I correct that the papers are from 2003 and 2004 >>respectively. Has much changed in gbde since then? > >Nope. One thing that puzzled me about the way gbde is integrated with the FreeBSD boot sequence is that it's not possible to boot without entering the correct gbde pass phrase. I assumed that if the correct pass phrase is not entered the specified number of times, three by default, the boot should proceed without attaching the encrypted partition. But at present, if the correct pass phrase is not entered, the system goes into a single user mode, but exiting from it to a multi-user mode again gets one to gbde pass phrase prompt. So it's not possible to boot at all without attaching the gbde encrypted partition. Perhaps this can be configured via some rc* options? The reason is that even a laptop can have multiple users, not all of whom need/should mount any or all encrypted partitions. And a wish - please describe "nuke" and "destroy" options more explicitly. The man page is extremely terse on this. Given the seriosness of the consequences - loss of all data on encrypted partition(?) - would be great to know exactly what would happen. The man page says both options will invalidate the masterkey. Does this mean that encrypted data cannot be recovered? This is my guess, based on reading your 2 papers. Many thanks for gbde. Anton