Hi
[Sorry for the late answer]
On 4/19/07, Francis Moreau [EMAIL PROTECTED] wrote:
On 4/17/07, Roland Dreier [EMAIL PROTECTED] wrote:
It seems trivial to keep the last key you were given and do a quick
memcmp in your setkey method to see if it's different from the last
key you
On 4/17/07, Herbert Xu [EMAIL PROTECTED] wrote:
On Mon, Apr 16, 2007 at 10:37:01AM +0200, Francis Moreau wrote:
BTW, here are figures I got with 2 different versions of the driver
when using tcrypt module. The second being the result with the
optimized driver (no key reloading on each
On Tue, Apr 17, 2007 at 04:01:51PM +0200, Francis Moreau ([EMAIL PROTECTED])
wrote:
On 4/17/07, Herbert Xu [EMAIL PROTECTED] wrote:
Yep. We don't need such a flag anyway. All we need is a way to tweak
the priority and Bob's your uncle.
Could you elaborate please, I don't see how you
On 4/17/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
OK, I tried to cook up something very simple. Since I don't know this
code, please be indulgent when reading the following patch ;)
Which means that after one has loaded ecryptfs module it can not use
ipsec and dm-crypt if there is only
Again, my code is faster only because I skip the key loading in
cia_encrypt method. Actually the gain is bigger in decryption mode
than in encryption one because I also generate the decryption key for
each block.
I wonder if there's some way you can cache the last caller and reload
the
I wonder if there's some way you can cache the last caller and reload
the key lazily (only when it changes).
yes something that allows crypto drivers to detect if the key has
changed would be good.
It seems trivial to keep the last key you were given and do a quick
memcmp in your
Francis Moreau [EMAIL PROTECTED] wrote:
On 4/17/07, Herbert Xu [EMAIL PROTECTED] wrote:
Actually, I was referring to your AES module :)
Well I don't if I can do that unfortunately.
What's the problem?
Actually there's nothing really interesting in this code, only key or
acc loadings and
On 4/17/07, Roland Dreier [EMAIL PROTECTED] wrote:
Again, my code is faster only because I skip the key loading in
cia_encrypt method. Actually the gain is bigger in decryption mode
than in encryption one because I also generate the decryption key for
each block.
I wonder if there's
On 4/17/07, Herbert Xu [EMAIL PROTECTED] wrote:
Francis Moreau [EMAIL PROTECTED] wrote:
On 4/17/07, Herbert Xu [EMAIL PROTECTED] wrote:
Actually, I was referring to your AES module :)
Well I don't if I can do that unfortunately.
What's the problem?
Always the same problem. Some stupid
On Mon, Apr 16, 2007 at 10:37:01AM +0200, Francis Moreau wrote:
BTW, here are figures I got with 2 different versions of the driver
when using tcrypt module. The second being the result with the
optimized driver (no key reloading on each block):
normal version:
test 4 (128 bit key, 8192
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
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
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
13 matches
Mail list logo
