lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 28 Aug 2017 10:22:25 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     Anand Jain <anand.jain@...cle.com>
Cc:     Eric Biggers <ebiggers3@...il.com>, linux-fscrypt@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        linux-ext4@...r.kernel.org, Jaegeuk Kim <jaegeuk@...nel.org>,
        Richard Weinberger <richard@....at>,
        Michael Halcrow <mhalcrow@...gle.com>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH] fscrypt: add a documentation file for filesystem-level
 encryption

On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
> > If *no* applications care whether the filenames are encrypted or not, sure.
> > But are you absolutely sure that no applications care?  How do you know?  And what
> > is the advantage of not encrypting the filenames anyway?  It is better to
> > encrypt by default.
> > 
>  File-name is a kind of File-system semantic and altering based on the on
> the user key context does not guarantee the system will be compatible with
> all their legacy applications.

In theory we could make it optional whether or not file names are
encrypted.  But that means extra complexity, and extra complexity
means potential bugs and vulnerabilities --- both potential
implementation bugs, vulnerabilities caused by users getting confused
by how they configure the system settings.  So in general with
security systems it's better to limit the complexity to the bare
minimum.

The only case which you've come up with in terms of potential
vulnerabilities is backup and restore, and backup and restore is
complicated for a number of numbers, since you need to be able to
backup and restore not just the file name and the encrypted data
blocks, but also the encrypted per-file key.  So getting this right
will almost certainly require that the backup/restore software be
fscrypt aware.

Hence, making the encryption of the filenames optional doesn't just to
make life easier for backup/restore isn't a compelling argument, since
the backup/restore program is going to have to have special case
handling for fscrypt protected file systems *anyway*.

Cheers,

					- Ted

Powered by blists - more mailing lists