From: Eric Biggers
Now that we have a key_hash field which securely identifies a master key
payload, introduce a cache of the HMAC transforms for the master keys
currently in use for inodes using v2+ encryption policies. The entries
in this cache are called 'struct fscrypt_master_key' and are id
From: Eric Biggers
In struct fscrypt_info, ->ci_master_key is the master key descriptor,
not the master key itself. In preparation for introducing a struct
fscrypt_master_key and making ->ci_master_key point to it, rename the
existing ->ci_master_key to ->ci_master_key_descriptor.
Signed-off-by
From: Eric Biggers
By design, the keys which userspace provides in the keyring are not used
to encrypt data directly. Instead, a KDF (Key Derivation Function) is
used to derive a unique encryption key for each inode, given a "master"
key and a nonce. The current KDF encrypts the master key with
From: Eric Biggers
Currently, while a fscrypt master key is required to have a certain
description in the keyring, its payload is never verified to be correct.
While sufficient for well-behaved userspace, this is insecure in a
multi-user system where a user has been given only read-only access to
From: Eric Biggers
Since v2 encryption policies are opt-in, take the opportunity to also
drop support for the legacy filesystem-specific key description prefixes
"ext4:", "f2fs:", and "ubifs:", instead requiring the generic prefix
"fscrypt:". The generic prefix is preferred since it works for al
From: Eric Biggers
Currently, the fscrypt_context (i.e. the encryption xattr) does not
contain a cryptographically secure identifier for the master key's
payload. Therefore it's not possible to verify that the correct key was
supplied, which is problematic in multi-user scenarios. To make this
From: Eric Biggers
This patch series solves two major problems which filesystem-level
encryption has currently. First, the user-supplied master keys are not
verified, which means a malicious user can provide the wrong key for
another user's file and cause a DOS attack or worse. This flaw has be
On 07/12/17 09:20 AM, Steffen Klassert wrote:
> On Tue, Jul 11, 2017 at 11:53:11AM -0700, Dave Watson wrote:
> > On 07/11/17 08:29 AM, Steffen Klassert wrote:
> > > Sorry for replying to old mail...
> > > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx)
> > > > +{
> > >
> > > ..
Dear Stephan,
Thank you for the quick response.
On 07/12/17 19:28, Stephan Müller wrote:
Am Mittwoch, 12. Juli 2017, 12:59:58 CEST schrieb Paul Menzel:
Building CRYPTO_RSA not as module, but into the Linux kernel,
`rsa_init()` takes 130 ms on an ASRock E350M1.
(Timings are shown by adding
Am Mittwoch, 12. Juli 2017, 12:59:58 CEST schrieb Paul Menzel:
Hi Paul,
> Dear Linux crypto folks,
>
>
> Building CRYPTO_RSA not as module, but into the Linux kernel,
> `rsa_init()` takes 130 ms on an ASRock E350M1.
>
> (Timings are shown by adding `initcall_debug` to Linux command line [1].
>
Dear Linux crypto folks,
Building CRYPTO_RSA not as module, but into the Linux kernel,
`rsa_init()` takes 130 ms on an ASRock E350M1.
(Timings are shown by adding `initcall_debug` to Linux command line [1].
The times are visualized by `analyze_boot.py` from pm-graph [2] or
`systemd-bootchar
On Tue, Jun 20, 2017 at 11:35:50AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The functions cvm_encrypt, cvm_decrypt, cvm_xts_setkey and
> cvm_enc_dec_init does not need to be in global scope, so make
> them static.
>
> Signed-off-by: Colin Ian King
Patch applied. Thanks.
--
Email:
On Wed, Jun 28, 2017 at 03:27:10PM +0200, David Gstir wrote:
> Certain cipher modes like CTS expect the IV (req->info) of
> ablkcipher_request (or equivalently req->iv of skcipher_request) to
> contain the last ciphertext block when the {en,de}crypt operation is done.
> This is currently not the ca
On Fri, Jun 23, 2017 at 07:45:11PM +0530, Harsh Jain wrote:
> Thsi patch fixes calling "crypto_alloc_cipher" call in bottom halves.
> Pre allocate aes cipher required to update Tweak value for XTS.
>
> Signed-off-by: Harsh Jain
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gon
On Fri, Jul 07, 2017 at 04:57:06PM +0300, Horia Geantă wrote:
> Driver does not properly handle the case when signals interrupt
> wait_for_completion_interruptible():
> -it does not check for return value
> -completion structure is allocated on stack; in case a signal interrupts
> the sleep, it wil
On Wed, Jun 28, 2017 at 10:22:03AM +0300, Gilad Ben-Yossef wrote:
> The Atmel SHA driver was treating -EBUSY as indication of queueing
> to backlog without checking that backlog is enabled for the request.
>
> Fix it by checking request flags.
>
> Signed-off-by: Gilad Ben-Yossef
Patch applied.
On Mon, Jul 03, 2017 at 12:37:59PM +0200, Harald Freudenberger wrote:
> Currently /dev/hwrng uses default device node permissions
> which is 0600. So by default the device node is not accessible
> by an ordinary user. Some distros do rewrite the device node
> permissions via udev rule, others don't
On Tue, Jul 11, 2017 at 11:53:11AM -0700, Dave Watson wrote:
> On 07/11/17 08:29 AM, Steffen Klassert wrote:
> > Sorry for replying to old mail...
> > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx)
> > > +{
> >
> > ...
> >
> > > +
> > > + if (!sw_ctx->aead_send) {
> > > +
18 matches
Mail list logo
