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
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
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
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.
+
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
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
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/
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
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
> + * 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
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 +-
&
11 matches
Mail list logo