On Mon, Aug 28, 2017 at 08:18:55PM +0800, Anand Jain wrote:
>
>
> On 08/23/2017 01:36 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
>
> I think AE is the only good solution for this, File-name encryption at
> this stage won't solve any kind
Hi Anand,
On Tue, Aug 29, 2017 at 11:54:47AM +0800, Anand Jain wrote:
>
> BTRFS has an experimental fscrypt implementation[1] which does not
> include the file-name encryption part it should be included but as
> an optional since not all uses cases saves sensitive information in
> the file-name.
Hi Anand,
On Mon, Aug 28, 2017 at 08:18:46PM +0800, Anand Jain wrote:
>
>
> On 08/23/2017 01:07 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
> >>
> >>
> >>On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >>>On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Ja
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 s
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
On 08/23/2017 01:07 AM, Eric Biggers wrote:
On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
On 08/22/2017 10:55 AM, Eric Biggers wrote:
On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
Hi Eric,
How about a section on the threat model specific to the file-name ?
On 08/23/2017 01:36 AM, Eric Biggers wrote:
On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
I think AE is the only good solution for this, File-name encryption at
this stage won't solve any kind of Evil Maid attack, (as it was quoted
somewhere else in ML).
Further, below,
On Tue, Aug 22, 2017 at 11:35:20PM +0800, Anand Jain wrote:
> >>
> >> I think AE is the only good solution for this, File-name encryption at
> >>this stage won't solve any kind of Evil Maid attack, (as it was quoted
> >>somewhere else in ML).
> >>
> >>
> >> Further, below, is define but not use
On Tue, Aug 22, 2017 at 11:33:51PM +0800, Anand Jain wrote:
>
>
> On 08/22/2017 10:55 AM, Eric Biggers wrote:
> >On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
> >>
> >>Hi Eric,
> >>
> >> How about a section on the threat model specific to the file-name ?
> >>
> >> (Sorry if I am
+fscrypt is not guaranteed to protect confidentiality or authenticity
+if an attacker is able to manipulate the filesystem offline prior to
+an authorized user later accessing the filesystem.
How does fscrypt / Android protect against Evil Maid attack. ?
_However_, an "Evil Maid" attacke
On 08/22/2017 10:55 AM, Eric Biggers wrote:
On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
Hi Eric,
How about a section on the threat model specific to the file-name ?
(Sorry if I am missing something).
Thanks, Anand
It's already mentioned that filenames are encrypted:
On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote:
>
>
>
> > > > +fscrypt is not guaranteed to protect confidentiality or authenticity
> > > > +if an attacker is able to manipulate the filesystem offline prior to
> > > > +an authorized user later accessing the filesystem.
> > >
> > >
On Tue, Aug 22, 2017 at 10:22:13AM +0800, Anand Jain wrote:
>
> I think AE is the only good solution for this, File-name encryption at
> this stage won't solve any kind of Evil Maid attack, (as it was quoted
> somewhere else in ML).
AE doesn't help at all against the Evil Maid attack, since the
On Tue, Aug 22, 2017 at 10:22:30AM +0800, Anand Jain wrote:
>
> Hi Eric,
>
> How about a section on the threat model specific to the file-name ?
>
> (Sorry if I am missing something).
>
> Thanks, Anand
It's already mentioned that filenames are encrypted: "fscrypt protects the
confidentiali
Hi Eric,
How about a section on the threat model specific to the file-name ?
(Sorry if I am missing something).
Thanks, Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
+fscrypt is not guaranteed to protect confidentiality or authenticity
+if an attacker is able to manipulate the filesystem offline prior to
+an authorized user later accessing the filesystem.
How does fscrypt / Android protect against Evil Maid attack. ?
_However_, an "Evil Maid" attack
On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote:
>
>
> >+fscrypt is not guaranteed to protect confidentiality or authenticity
> >+if an attacker is able to manipulate the filesystem offline prior to
> >+an authorized user later accessing the filesystem.
>
> How does fscrypt / Android
On Sat, Aug 19, 2017 at 10:32:27PM -0400, Theodore Ts'o wrote:
> On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> > On Aug 18, 2017, at 1:47 PM, Eric Biggers wrote:
> > > +Key hierarchy
> > > +=
> > > +
> > > +Master Keys
> > > +---
> > > +
> > > +Userspace sho
On Mon, Aug 21, 2017 at 09:44:11PM +0800, Anand Jain wrote:
>
>
> > +fscrypt is not guaranteed to protect confidentiality or authenticity
> > +if an attacker is able to manipulate the filesystem offline prior to
> > +an authorized user later accessing the filesystem.
>
> How does fscrypt / Andr
+fscrypt is not guaranteed to protect confidentiality or authenticity
+if an attacker is able to manipulate the filesystem offline prior to
+an authorized user later accessing the filesystem.
How does fscrypt / Android protect against Evil Maid attack. ?
Thanks, Anand
--
To unsubscribe from
On Fri, Aug 18, 2017 at 03:06:52PM -0600, Andreas Dilger wrote:
> On Aug 18, 2017, at 1:47 PM, Eric Biggers wrote:
> > +Key hierarchy
> > +=
> > +
> > +Master Keys
> > +---
> > +
> > +Userspace should generate master keys either using a cryptographically
> > +secure random numb
On Aug 18, 2017, at 1:47 PM, Eric Biggers wrote:
> +Key hierarchy
> +=
> +
> +Master Keys
> +---
> +
> +Userspace should generate master keys either using a cryptographically
> +secure random number generator, e.g. by reading from ``/dev/urandom``
> +or calling getrandom(), or
From: Eric Biggers
Perhaps long overdue, add a documentation file for filesystem-level
encryption, a.k.a. fscrypt or fs/crypto/, to the Documentation
directory. The new file is based loosely on the latest version of the
"EXT4 Encryption Design Document (public version)" Google Doc, but with
many
23 matches
Mail list logo