From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <htd@fancy-poultry.org>
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9])
	by mail.saout.de (Postfix) with ESMTP
	for <dm-crypt@saout.de>; Mon, 12 Oct 2009 14:53:26 +0200 (CEST)
Received: from liesel.fritha.org (localhost [127.0.0.1])
	by liesel.fritha.org (Postfix) with ESMTP id A4F041956E03
	for <dm-crypt@saout.de>; Mon, 12 Oct 2009 14:53:24 +0200 (CEST)
Date: Mon, 12 Oct 2009 14:53:24 +0200
Message-ID: <87ococdb97.wl%htd@fancy-poultry.org>
From: Heinz Diehl <htd@fancy-poultry.org>
In-Reply-To: <20091012111229.64a374ac@tanana.suse.de>
References: <1253821495.4683.25.camel@P7230>
	<20090929134450.76dab774@tanana.suse.de>
	<loom.20091012T011520-617@post.gmane.org>
	<20091012111229.64a374ac@tanana.suse.de>
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [dm-crypt] Shared library for cryptsetup
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
	<mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

At Mon, 12 Oct 2009 11:12:29 +0200,
Ludwig Nussel wrote:

> > Another reason is that tokentube allows for different deployment options: it's
> > possible to configure the system in such a way that the user's auth files (key
> > files) are in fact owned by the user. That's not a common scenario but I've
> > seen environments which required such setups.
 
> Wouldn't that expose the master key to the users?

This is exactly what I thought, too.
 
> > > Also, as long as you're using local authentication you don't need to
> > > store the password for pam authentication. Should be sufficient to
> > > just reconfigure the displaymanager to auto login the user that
> > > unlocked the root device.

Adding a big amount of complex code to an already working solution raises the chance of
putting a security hole into it. And there is also to consider that by far not
all users are using PAM at all. 
  
Generally, I think the level of adding complex and new code to cryptographic
software should be a hundred times higher than usual, because every line of
code raises the possibility of introducing a flaw, which often renders the whole
software unuseable.