Re: [CRYPTO] is it really optimized ?
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 eCryptfs asks for
a aes cipher it will pass aes name and since aes-foo has a higher
priority then the cypto core will return aes-foo cipher, right ? But
in this scheme, eCryptfs has not a higher priority than other kernel
users. How can I prevent others to use aes-foo ?
You would assign aes-foo a lower priority and then tell eCryptfs to
use aes-foo instead of aes.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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
Re: [CRYPTO] is it really optimized ?
On 4/14/07, Herbert Xu [EMAIL PROTECTED] 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 eCryptfs asks for a aes cipher it will pass aes name and since aes-foo has a higher priority then the cypto core will return aes-foo cipher, right ? But in this scheme, eCryptfs has not a higher priority than other kernel users. How can I prevent others to use aes-foo ? You would assign aes-foo a lower priority and then tell eCryptfs to use aes-foo instead of aes. ok but do you think it's safe to assume that no others parts of the kernel will request aes-foo ? Remember that the main point is to optimize aes-foo ? I would say that it would be better if aes-foo could raise a flag for example indicating to the crypto core that this algo can be instatiate only one time... thanks -- Francis - 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
Re: [CRYPTO] is it really optimized ?
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 eCryptfs asks for a aes cipher it will pass aes name and since aes-foo has a higher priority then the cypto core will return aes-foo cipher, right ? But in this scheme, eCryptfs has not a higher priority than other kernel users. How can I prevent others to use aes-foo ? 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::ecryptfs_cipher_code_str_map[] and associated functions). This is because eCryptfs needs to pick a cipher code (RFC2440-ish) to identify the cipher in the encrypted file metadata. Shall I go ahead with a patch to add support for the '-' qualifier? Mike - 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
