[PATCH 5/6] fscrypt: cache the HMAC transform for each master key

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

[PATCH 2/6] fscrypt: rename ->ci_master_key to ->ci_master_key_descriptor

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

[PATCH 3/6] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

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

[PATCH 4/6] fscrypt: verify that the correct master key was supplied

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

[PATCH 6/6] fscrypt: for v2 policies, support "fscrypt:" key prefix only

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

[PATCH 1/6] fscrypt: add v2 encryption context and policy

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

[PATCH 0/6] fscrypt: key verification and KDF improvement

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

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

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) > > > > +{ > > > > > >

Re: Decreasing time for `rsa_init`

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

Re: Decreasing time for `rsa_init`

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].

Decreasing time for `rsa_init`

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

Re: [PATCH] crypto: cavium: make several functions static

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

Re: [PATCH] crypto: caam - properly set IV after {en,de}crypt

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

Re: [PATCH] crypto: chcr: Avoid algo allocation in softirq.

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

Re: [RFC PATCH] crypto: caam - fix signals handling

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

Re: [BUGFIX] crypto: atmel: only treat EBUSY as transient if backlog

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

Re: [PATCH] crypto: change hwrng device default permissions to 0444

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

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

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) { > > > +