On Sun, 2 Sep 2007, Herbert Xu wrote:
>
> On Sun, Sep 02, 2007 at 02:39:15AM +0530, Satyam Sharma wrote:
> >
> > Tangential, but I've often wondered what are the upsides of keeping
> > CONFIG_CRYPTO_ALGAPI as a separate config option in the first place? Every
>
ONFIG_CRYPTO
in the Makefile, thusly:
[PATCH] crypto: Remove CONFIG_CRYPTO_ALGAPI config option
Because all other options in crypto/ end up selecting it anyway. So let's
make it a default part of the rest of "core" crypto stuff, that gets built
whenever CONFIG_CRYPTO =
On Tue, 31 Jul 2007, Felipe Balbi wrote:
> On 7/31/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > [...]
> > Ugh, you should at least be checking if you've built the kernel with the
> > same config options :-) Of course, if you did a simple "make oldc
Hi,
On Tue, 31 Jul 2007, Felipe Balbi wrote:
> On 7/31/07, Akinobu Mita <[EMAIL PROTECTED]> wrote:
> > > > "Failed to setup dm-crypt key mapping.
> > > > Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and
> > > > verify that /dev/hda4 contains at least 133 sectors.
> > > > Fai
Hi Gautam,
[ trimmed Cc: list ]
On 7/10/07, Gautam Singaraju <[EMAIL PROTECTED]> wrote:
All,
I am planning to work on some experimental crypto support in kernel
level. For the development, I need to use BigNum library. I wanted to
load a minimal BigNum library into memory for high performance.
On 6/26/07, Alexander Wuerstlein
<[EMAIL PROTECTED]> wrote:
[...]
Nope. I unluckily wrote 'userspace' where I should have said something else:
Chain-of-trust is handled in what I would label 'Adminspace' (Where we do the
signing as in points 1 and 2). There is a very small number of signatures (i
On 6/25/07, Alexander Wuerstlein
<[EMAIL PROTECTED]> wrote:
On 070622 21:40, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> [...]
> But first: Have you checked the digsig project? It's been doing
> (for some time) what your current patchset proposes -- and
> it uses pub
Hi Alexander, Johannes,
[ Added linux-crypto to Cc: ]
Wow, this is _one_ *intrusive* patchset indeed :-)
But first: Have you checked the digsig project? It's been doing
(for some time) what your current patchset proposes -- and
it uses public key cryptosystems for the key management,
which is d
Hi Richard,
On 5/1/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
Add LZO1X compression/decompression support to jffs2.
LZO's interface doesn't entirely match that required by jffs2 so a
buffer and memcpy is unavoidable.
Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>
---
[...]
+++ b/fs/jffs2
On 5/1/07, Richard Purdie <[EMAIL PROTECTED]> wrote:
+static int lzo_init(struct crypto_tfm *tfm)
+{
+ struct lzo_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ ctx->lzo_mem = vmalloc(LZO1X_MEM_COMPRESS);
+
+ if (!ctx->lzo_mem) {
+ vfree(ctx->lzo_mem);
Heh. What's (why's) t
Hi Mike,
On 4/15/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
On Sun, Apr 15, 2007 at 08:01:24PM +0530, Satyam Sharma wrote:
> I might be answering myself here, but clearly, removing the
> whitelist does not seem possible given the PGP-message-framework
> eCryptfs was designed
On 4/15/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
On 4/15/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
> Note that eCryptfs whitelists the cipher name (see
> fs/ecryptfs/crypto.c::ecryptfs_cipher_code_str_map[] and associated
> functions). This is because eCryptfs n
On 4/15/07, Michael Halcrow <[EMAIL PROTECTED]> wrote:
On Sun, Apr 15, 2007 at 05:34:19AM +1000, Herbert Xu wrote:
>
> You would assign "aes-foo" a lower priority and then tell eCryptfs to
> use "aes-foo" instead of "aes".
Note that eCryptfs whitelists the cipher name (see
fs/ecryptfs/crypto.c::
13 matches
Mail list logo
