On Tue, Jan 17, 2006 at 01:16:26PM +0300, Evgeniy Polyakov wrote:
>
> Yep.
> But it still requires some kind of parsing in kernel:
> what if we will have "deflate(a,b)", and "defalate(a, default_b)"?
> Will all such strings userspace parsing end up in userspace requests
> for tons of the same module, but different algorith strings?
> Although we can only allow to have "deflate" and "defalte(all parameters)"...

The only thing the kernel does is check if there is a crypto_alg
registered under that name.  If there is it allocates a tfm of
that type.  If it doesn't know about it's passed to user-space.
No parsing in the kernel at all apart from strcmp.

BTW, this doesn't mean that we can't have things like CBC/HMAC without
a user-space daemon.  For the common stuff needed by IPsec (md5-hmac,
aes-cbc, etc.) they can and should be preregistered.

> Such strings are perfectly fine, but what will happen when 
> someone calls "cbc(cbc(cbc(...(aes)))"?

That's fine.  Because the parsing of such unknown strings occur in
userspace we get to make up whatever rules you want.

However, in this case it's pretty simple.  CBC only accepts "base"
cipher algorithms.  While "aes" is a base algorithm, "cbc(aes)" is
not a "base" cipher algorithm.  Therefore this expression is invalid.
So is the expression "cbc(md5)".

> What if we create restriction and allow to only call
> "basic" algo creations, and then link them at setup() time?
> I.e. 
> tfm1 = tfm_alloc_method(xcbc);
> tfm2 = tfm_alloc_method(xcbc);
> tfm3 = tfm_alloc_cipher(aes);
> tfm2->setup(tfm3); // "cbc(aes)"
> tfm1->setup(tfm2); // "cbc(cbc(aes))"

Sure, I'm totally cool with preregistration for common cases.  This means
that 99% of the users won't need a user-space daemon to hang around.
However, we should maintain the potential to have arbitrary combinations
for maximum flexibility.

It's just that if you need that flexibility (e.g., hmac(xbc(cbc(aes)), 0x123)),
you'll have the pay the cost of keeping a user-space daemon around.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to