From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-api@vger.kernel.org,
linux-crypto@vger.kernel.org, keyrings@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>,
Satya Tangirala <satyat@google.com>
Subject: Re: [PATCH v7 09/16] fscrypt: add an HKDF-SHA512 implementation
Date: Mon, 29 Jul 2019 13:29:52 -0700 [thread overview]
Message-ID: <20190729202951.GG169027@gmail.com> (raw)
In-Reply-To: <20190728193949.GI6088@mit.edu>
On Sun, Jul 28, 2019 at 03:39:49PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> > deriving additional key material from the fscrypt master keys for v2
> > encryption policies. HKDF is a key derivation function built on top of
> > HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
> > "hmac(sha512)" transform allocated from the crypto API.
> >
> > We'll be using this to replace the AES-ECB based KDF currently used to
> > derive the per-file encryption keys. While the AES-ECB based KDF is
> > believed to meet the original security requirements, it is nonstandard
> > and has problems that don't exist in modern KDFs such as HKDF:
> >
> > 1. It's reversible. Given a derived key and nonce, an attacker can
> > easily compute the master key. This is okay if the master key and
> > derived keys are equally hard to compromise, but now we'd like to be
> > more robust against threats such as a derived key being compromised
> > through a timing attack, or a derived key for an in-use file being
> > compromised after the master key has already been removed.
> >
> > 2. It doesn't evenly distribute the entropy from the master key; each 16
> > input bytes only affects the corresponding 16 output bytes.
> >
> > 3. It isn't easily extensible to deriving other values or keys, such as
> > a public hash for securely identifying the key, or per-mode keys.
> > Per-mode keys will be immediately useful for Adiantum encryption, for
> > which fscrypt currently uses the master key directly, introducing
> > unnecessary usage constraints. Per-mode keys will also be useful for
> > hardware inline encryption, which is currently being worked on.
> >
> > HKDF solves all the above problems.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
>
> Unless I missed something there's nothing here which is fscrypt
> specific. Granted that it's somewhat unlikely that someone would want
> to implement (the very bloated) IKE from IPSEC in the kernel, I wonder
> if there might be other users of HKDF, and whether this would be
> better placed in lib/ or crypto/ instead of fs/crypto?
>
This is standard HKDF-SHA512; only the choice of parameters is fscrypt-specific.
So it could indeed use a common implementation of HKDF if one were available.
However, I don't think there are any other HKDF users in the kernel currently.
Also, while there was a patch to support HKDF via the crypto_rng API, there was
no consensus about whether this was actually the best way to add KDF support:
https://lore.kernel.org/linux-crypto/2423373.Zd5ThvQH5g@positron.chronox.de
So for now, to avoid unnecessarily blocking this patchset I think we should just
go with this implementation in fs/crypto/. It can always be changed later, once
we decide on the best way to add KDFs to the crypto API.
[To be clear: this patch already uses "hmac(sha512)" from the crypto API. It's
only the actual HKDF part that we're talking about here.
Also, its correctness is tested by the ciphertext verification xfstests.]
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v7 09/16] fscrypt: add an HKDF-SHA512 implementation
Date: Mon, 29 Jul 2019 20:29:52 +0000 [thread overview]
Message-ID: <20190729202951.GG169027@gmail.com> (raw)
In-Reply-To: <20190728193949.GI6088@mit.edu>
On Sun, Jul 28, 2019 at 03:39:49PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> > deriving additional key material from the fscrypt master keys for v2
> > encryption policies. HKDF is a key derivation function built on top of
> > HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
> > "hmac(sha512)" transform allocated from the crypto API.
> >
> > We'll be using this to replace the AES-ECB based KDF currently used to
> > derive the per-file encryption keys. While the AES-ECB based KDF is
> > believed to meet the original security requirements, it is nonstandard
> > and has problems that don't exist in modern KDFs such as HKDF:
> >
> > 1. It's reversible. Given a derived key and nonce, an attacker can
> > easily compute the master key. This is okay if the master key and
> > derived keys are equally hard to compromise, but now we'd like to be
> > more robust against threats such as a derived key being compromised
> > through a timing attack, or a derived key for an in-use file being
> > compromised after the master key has already been removed.
> >
> > 2. It doesn't evenly distribute the entropy from the master key; each 16
> > input bytes only affects the corresponding 16 output bytes.
> >
> > 3. It isn't easily extensible to deriving other values or keys, such as
> > a public hash for securely identifying the key, or per-mode keys.
> > Per-mode keys will be immediately useful for Adiantum encryption, for
> > which fscrypt currently uses the master key directly, introducing
> > unnecessary usage constraints. Per-mode keys will also be useful for
> > hardware inline encryption, which is currently being worked on.
> >
> > HKDF solves all the above problems.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
>
> Unless I missed something there's nothing here which is fscrypt
> specific. Granted that it's somewhat unlikely that someone would want
> to implement (the very bloated) IKE from IPSEC in the kernel, I wonder
> if there might be other users of HKDF, and whether this would be
> better placed in lib/ or crypto/ instead of fs/crypto?
>
This is standard HKDF-SHA512; only the choice of parameters is fscrypt-specific.
So it could indeed use a common implementation of HKDF if one were available.
However, I don't think there are any other HKDF users in the kernel currently.
Also, while there was a patch to support HKDF via the crypto_rng API, there was
no consensus about whether this was actually the best way to add KDF support:
https://lore.kernel.org/linux-crypto/2423373.Zd5ThvQH5g@positron.chronox.de
So for now, to avoid unnecessarily blocking this patchset I think we should just
go with this implementation in fs/crypto/. It can always be changed later, once
we decide on the best way to add KDFs to the crypto API.
[To be clear: this patch already uses "hmac(sha512)" from the crypto API. It's
only the actual HKDF part that we're talking about here.
Also, its correctness is tested by the ciphertext verification xfstests.]
- Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v7 09/16] fscrypt: add an HKDF-SHA512 implementation
Date: Mon, 29 Jul 2019 13:29:52 -0700 [thread overview]
Message-ID: <20190729202951.GG169027@gmail.com> (raw)
In-Reply-To: <20190728193949.GI6088@mit.edu>
On Sun, Jul 28, 2019 at 03:39:49PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> > deriving additional key material from the fscrypt master keys for v2
> > encryption policies. HKDF is a key derivation function built on top of
> > HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
> > "hmac(sha512)" transform allocated from the crypto API.
> >
> > We'll be using this to replace the AES-ECB based KDF currently used to
> > derive the per-file encryption keys. While the AES-ECB based KDF is
> > believed to meet the original security requirements, it is nonstandard
> > and has problems that don't exist in modern KDFs such as HKDF:
> >
> > 1. It's reversible. Given a derived key and nonce, an attacker can
> > easily compute the master key. This is okay if the master key and
> > derived keys are equally hard to compromise, but now we'd like to be
> > more robust against threats such as a derived key being compromised
> > through a timing attack, or a derived key for an in-use file being
> > compromised after the master key has already been removed.
> >
> > 2. It doesn't evenly distribute the entropy from the master key; each 16
> > input bytes only affects the corresponding 16 output bytes.
> >
> > 3. It isn't easily extensible to deriving other values or keys, such as
> > a public hash for securely identifying the key, or per-mode keys.
> > Per-mode keys will be immediately useful for Adiantum encryption, for
> > which fscrypt currently uses the master key directly, introducing
> > unnecessary usage constraints. Per-mode keys will also be useful for
> > hardware inline encryption, which is currently being worked on.
> >
> > HKDF solves all the above problems.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
>
> Unless I missed something there's nothing here which is fscrypt
> specific. Granted that it's somewhat unlikely that someone would want
> to implement (the very bloated) IKE from IPSEC in the kernel, I wonder
> if there might be other users of HKDF, and whether this would be
> better placed in lib/ or crypto/ instead of fs/crypto?
>
This is standard HKDF-SHA512; only the choice of parameters is fscrypt-specific.
So it could indeed use a common implementation of HKDF if one were available.
However, I don't think there are any other HKDF users in the kernel currently.
Also, while there was a patch to support HKDF via the crypto_rng API, there was
no consensus about whether this was actually the best way to add KDF support:
https://lore.kernel.org/linux-crypto/2423373.Zd5ThvQH5g@positron.chronox.de
So for now, to avoid unnecessarily blocking this patchset I think we should just
go with this implementation in fs/crypto/. It can always be changed later, once
we decide on the best way to add KDFs to the crypto API.
[To be clear: this patch already uses "hmac(sha512)" from the crypto API. It's
only the actual HKDF part that we're talking about here.
Also, its correctness is tested by the ciphertext verification xfstests.]
- Eric
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
Paul Crowley <paulcrowley@google.com>
Subject: Re: [f2fs-dev] [PATCH v7 09/16] fscrypt: add an HKDF-SHA512 implementation
Date: Mon, 29 Jul 2019 13:29:52 -0700 [thread overview]
Message-ID: <20190729202951.GG169027@gmail.com> (raw)
In-Reply-To: <20190728193949.GI6088@mit.edu>
On Sun, Jul 28, 2019 at 03:39:49PM -0400, Theodore Y. Ts'o wrote:
> On Fri, Jul 26, 2019 at 03:41:34PM -0700, Eric Biggers wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > Add an implementation of HKDF (RFC 5869) to fscrypt, for the purpose of
> > deriving additional key material from the fscrypt master keys for v2
> > encryption policies. HKDF is a key derivation function built on top of
> > HMAC. We choose SHA-512 for the underlying unkeyed hash, and use an
> > "hmac(sha512)" transform allocated from the crypto API.
> >
> > We'll be using this to replace the AES-ECB based KDF currently used to
> > derive the per-file encryption keys. While the AES-ECB based KDF is
> > believed to meet the original security requirements, it is nonstandard
> > and has problems that don't exist in modern KDFs such as HKDF:
> >
> > 1. It's reversible. Given a derived key and nonce, an attacker can
> > easily compute the master key. This is okay if the master key and
> > derived keys are equally hard to compromise, but now we'd like to be
> > more robust against threats such as a derived key being compromised
> > through a timing attack, or a derived key for an in-use file being
> > compromised after the master key has already been removed.
> >
> > 2. It doesn't evenly distribute the entropy from the master key; each 16
> > input bytes only affects the corresponding 16 output bytes.
> >
> > 3. It isn't easily extensible to deriving other values or keys, such as
> > a public hash for securely identifying the key, or per-mode keys.
> > Per-mode keys will be immediately useful for Adiantum encryption, for
> > which fscrypt currently uses the master key directly, introducing
> > unnecessary usage constraints. Per-mode keys will also be useful for
> > hardware inline encryption, which is currently being worked on.
> >
> > HKDF solves all the above problems.
> >
> > Signed-off-by: Eric Biggers <ebiggers@google.com>
>
> Unless I missed something there's nothing here which is fscrypt
> specific. Granted that it's somewhat unlikely that someone would want
> to implement (the very bloated) IKE from IPSEC in the kernel, I wonder
> if there might be other users of HKDF, and whether this would be
> better placed in lib/ or crypto/ instead of fs/crypto?
>
This is standard HKDF-SHA512; only the choice of parameters is fscrypt-specific.
So it could indeed use a common implementation of HKDF if one were available.
However, I don't think there are any other HKDF users in the kernel currently.
Also, while there was a patch to support HKDF via the crypto_rng API, there was
no consensus about whether this was actually the best way to add KDF support:
https://lore.kernel.org/linux-crypto/2423373.Zd5ThvQH5g@positron.chronox.de
So for now, to avoid unnecessarily blocking this patchset I think we should just
go with this implementation in fs/crypto/. It can always be changed later, once
we decide on the best way to add KDFs to the crypto API.
[To be clear: this patch already uses "hmac(sha512)" from the crypto API. It's
only the actual HKDF part that we're talking about here.
Also, its correctness is tested by the ciphertext verification xfstests.]
- Eric
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2019-07-29 20:29 UTC|newest]
Thread overview: 230+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 22:41 [PATCH v7 00/16] fscrypt: key management improvements Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 01/16] fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-28 15:08 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-28 15:08 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 02/16] fscrypt: use FSCRYPT_ prefix for uapi constants Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 03/16] fscrypt: use FSCRYPT_* definitions, not FS_* Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 04/16] fscrypt: add ->ci_inode to fscrypt_info Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 15:09 ` Theodore Y. Ts'o
2019-07-28 15:09 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 15:09 ` Theodore Y. Ts'o
2019-07-28 15:09 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 05/16] fscrypt: refactor v1 policy key setup into keysetup_legacy.c Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 15:40 ` Theodore Y. Ts'o
2019-07-28 15:40 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 15:40 ` Theodore Y. Ts'o
2019-07-28 15:40 ` Theodore Y. Ts'o
2019-07-29 19:37 ` Eric Biggers
2019-07-29 19:37 ` Eric Biggers
2019-07-29 19:37 ` Eric Biggers
2019-07-29 19:37 ` [f2fs-dev] " Eric Biggers
2019-07-26 22:41 ` [PATCH v7 06/16] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 18:50 ` Theodore Y. Ts'o
2019-07-28 18:50 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 18:50 ` Theodore Y. Ts'o
2019-07-28 18:50 ` Theodore Y. Ts'o
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` Eric Biggers
2019-07-29 19:46 ` [f2fs-dev] " Eric Biggers
2019-07-29 20:14 ` Theodore Y. Ts'o
2019-07-29 20:14 ` Theodore Y. Ts'o
2019-07-29 20:14 ` Theodore Y. Ts'o
2019-07-29 20:14 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 07/16] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 19:24 ` Theodore Y. Ts'o
2019-07-28 19:24 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 19:24 ` Theodore Y. Ts'o
2019-07-28 19:24 ` Theodore Y. Ts'o
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` Eric Biggers
2019-07-29 19:58 ` [f2fs-dev] " Eric Biggers
2019-07-31 18:38 ` Eric Biggers
2019-07-31 18:38 ` Eric Biggers
2019-07-31 18:38 ` Eric Biggers
2019-07-31 18:38 ` [f2fs-dev] " Eric Biggers
2019-07-31 23:38 ` Theodore Y. Ts'o
2019-07-31 23:38 ` Theodore Y. Ts'o
2019-07-31 23:38 ` Theodore Y. Ts'o
2019-07-31 23:38 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-01 1:11 ` Eric Biggers
2019-08-01 1:11 ` Eric Biggers
2019-08-01 1:11 ` Eric Biggers
2019-08-01 1:11 ` [f2fs-dev] " Eric Biggers
2019-08-01 1:11 ` Eric Biggers
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 5:31 ` Theodore Y. Ts'o
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` Eric Biggers
2019-08-01 18:35 ` [f2fs-dev] " Eric Biggers
2019-08-01 18:46 ` Eric Biggers
2019-08-01 18:46 ` Eric Biggers
2019-08-01 18:46 ` Eric Biggers
2019-08-01 18:46 ` [f2fs-dev] " Eric Biggers
2019-08-01 22:04 ` Eric Biggers
2019-08-01 22:04 ` Eric Biggers
2019-08-01 22:04 ` Eric Biggers
2019-08-01 22:04 ` [f2fs-dev] " Eric Biggers
2019-08-02 4:38 ` Eric Biggers
2019-08-02 4:38 ` Eric Biggers
2019-08-02 4:38 ` Eric Biggers
2019-08-02 4:38 ` [f2fs-dev] " Eric Biggers
2019-08-12 14:16 ` Theodore Y. Ts'o
2019-08-12 14:16 ` Theodore Y. Ts'o
2019-08-12 14:16 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 14:16 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 08/16] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 19:30 ` Theodore Y. Ts'o
2019-07-28 19:30 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 19:30 ` Theodore Y. Ts'o
2019-07-28 19:30 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 09/16] fscrypt: add an HKDF-SHA512 implementation Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-28 19:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-28 19:39 ` Theodore Y. Ts'o
2019-07-29 20:29 ` Eric Biggers [this message]
2019-07-29 20:29 ` [f2fs-dev] " Eric Biggers
2019-07-29 20:29 ` Eric Biggers
2019-07-29 20:29 ` Eric Biggers
2019-07-29 21:42 ` James Bottomley
2019-07-29 21:42 ` [f2fs-dev] " James Bottomley
2019-07-29 21:42 ` James Bottomley
2019-07-29 21:42 ` James Bottomley
2019-07-26 22:41 ` [PATCH v7 10/16] fscrypt: v2 encryption policy support Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:17 ` Theodore Y. Ts'o
2019-07-28 21:17 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:17 ` Theodore Y. Ts'o
2019-07-28 21:17 ` Theodore Y. Ts'o
2019-07-29 20:46 ` Eric Biggers
2019-07-29 20:46 ` [f2fs-dev] " Eric Biggers
2019-07-29 20:46 ` Eric Biggers
2019-07-29 20:46 ` Eric Biggers
2019-07-26 22:41 ` [PATCH v7 11/16] fscrypt: allow unprivileged users to add/remove keys for v2 policies Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:22 ` Theodore Y. Ts'o
2019-07-28 21:22 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:22 ` Theodore Y. Ts'o
2019-07-28 21:22 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 12/16] fscrypt: require that key be added when setting a v2 encryption policy Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 13/16] ext4: wire up new fscrypt ioctls Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-28 21:24 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 14/16] f2fs: " Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-30 0:36 ` Jaegeuk Kim
2019-07-30 0:36 ` [f2fs-dev] " Jaegeuk Kim
2019-07-30 0:36 ` Jaegeuk Kim
2019-07-30 0:36 ` Jaegeuk Kim
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` [f2fs-dev] " Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 8:10 ` Chao Yu
2019-08-02 17:31 ` Eric Biggers
2019-08-02 17:31 ` Eric Biggers
2019-08-02 17:31 ` Eric Biggers
2019-08-02 17:31 ` [f2fs-dev] " Eric Biggers
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` Chao Yu
2019-08-04 9:42 ` [f2fs-dev] " Chao Yu
2019-07-26 22:41 ` [PATCH v7 15/16] ubifs: " Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-30 0:39 ` Theodore Y. Ts'o
2019-07-30 0:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-30 0:39 ` Theodore Y. Ts'o
2019-07-30 0:39 ` Theodore Y. Ts'o
2019-07-26 22:41 ` [PATCH v7 16/16] fscrypt: document the new ioctls and policy version Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` Eric Biggers
2019-07-26 22:41 ` [f2fs-dev] " Eric Biggers
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 2:00 ` [f2fs-dev] " Theodore Y. Ts'o
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 2:00 ` Theodore Y. Ts'o
2019-07-29 21:36 ` Eric Biggers
2019-07-29 21:36 ` Eric Biggers
2019-07-29 21:36 ` Eric Biggers
2019-07-29 21:36 ` [f2fs-dev] " Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190729202951.GG169027@gmail.com \
--to=ebiggers@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paulcrowley@google.com \
--cc=satyat@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.