Re: [PATCH 0/6] MODSIGN: Kernel module signing

2007-02-14 Thread Michael Halcrow
On Wed, Feb 14, 2007 at 09:59:37PM +, David Howells wrote: Michael Halcrow [EMAIL PROTECTED] wrote: Right now, eCryptfs just delegates its modular exponentiation operations to a userspace daemon. If RSA ever finds its way into the kernel, I might tweak eCryptfs to use that instead

Re: [CRYPTO] is it really optimized ?

2007-04-14 Thread Michael Halcrow
On Sun, Apr 15, 2007 at 05:34:19AM +1000, Herbert Xu wrote: Francis Moreau [EMAIL PROTECTED] wrote: hmm yes indeed it should do the job, but I don't see how you do that. For example, let say I want to use aes-foo with eCryptfs. I can give a higher priority to aes-foo than aes one. When

Re: RSA support into kernel?

2007-07-06 Thread Michael Halcrow
On Fri, Jul 06, 2007 at 09:12:52PM +0800, Herbert Xu wrote: So far the only proposed user for RSA in-kernel seems to be module signing and I'm staying well away from that debate :) eCryptfs uses RSA. Right now it has to defer to a userspace daemon to perform the operation. Mike

Re: [PATCH 1/1]: Add countersize to CTR

2007-10-23 Thread Michael Halcrow
On Tue, Oct 23, 2007 at 03:26:29PM -0500, Joy Latten wrote: + unsigned int countersize; It's somewhat nicer to just use size_t in the kernel for these sorts of data types. If you care about the exact number of bytes used by the variable, types like u32 make the code more parsable. +

Re: [PATCH 1/1]: Add countersize to CTR

2007-10-23 Thread Michael Halcrow
On Wed, Oct 24, 2007 at 09:19:05AM +0800, Herbert Xu wrote: These paths can be triggered from user-space in future so printks are not appropriate. I am familiar with CryptoDev and Cryproc. Will you be implementing anything similar to what these projects are currently doing? Or do you have

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

2017-07-13 Thread Michael Halcrow
2 ioctl. It also would have > required userspace to start using a specific hash algorithm to create > the key descriptors, which would have made the API harder to use. > Perhaps it should have been done that way originally, but at this point > it seems better to keep the API

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

2017-07-17 Thread Michael Halcrow
emain supported for v1 encryption policies. > > Signed-off-by: Eric Biggers <ebigg...@google.com> Reviewed-by: Michael Halcrow <mhalc...@google.com> > --- > fs/crypto/fscrypt_private.h | 3 +-- > fs/crypto/keyinfo.c | 16 > fs/crypto/

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

2017-07-17 Thread Michael Halcrow
ecause key_hash is public information while raw_key is > secret information, it would have been very difficult to use raw_key as > a map key in a way that would prevent timing attacks while still being > scalable to a large number of entries. > > Signed-off-by: Eric Biggers <e

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

2017-07-14 Thread Michael Halcrow
se it avoids passing the > same key into different cryptographic primitives. > > We make the hash field 16 bytes long, as this should provide sufficient > collision and preimage resistance while not wasting too much space for > the encryption xattr. > > Signed-off-by: Eric Bigg

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

2017-07-14 Thread Michael Halcrow
> + * The master key with which this inode was "unlocked" > + * (only set for inodes that use a v2+ encryption policy) > + */ > + struct fscrypt_master_key *ci_master_key; > + > /* >* Cached fields from the fscrypt_context needed for

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

2017-07-14 Thread Michael Halcrow
d making ->ci_master_key point to it, rename the > existing ->ci_master_key to ->ci_master_key_descriptor. > > Signed-off-by: Eric Biggers <ebigg...@google.com> Acked-by: Michael Halcrow <mhalc...@google.com> > --- > fs/crypto/fscrypt_private.h | 2 +- &