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
> > >
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, 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 pushed to hardware, and set a flag if it is. Then only do
> > your set_key() if
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 pushed to hardware, and set a flag if it is. Then only do
your set_key() if you have a
> > 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 pushed to hardware, and set a flag if it is. Then only do
> > your set_key() if you have a new key to pass to hardware.
> >
> > I'm
On 4/17/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
> > 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
On Tue, Apr 17, 2007 at 06:18:42PM +0200, Francis Moreau ([EMAIL PROTECTED])
wrote:
> >If there are no another users, your code already has exclusive access.
>
> sorry I don't understand that.
Since there are no users except your module, you do have exclusive
access already, i.e. you can stop
> > 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
On Tue, Apr 17, 2007 at 05:34:12PM +0200, Francis Moreau ([EMAIL PROTECTED])
wrote:
> >Preventing anyone from using the module is incorrect.
> >How will you handle the case when you have only one algo registered and
> >it will be exclusively used by ecryptfs?
> >
>
> As I tried to explain, in
> 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
On 4/17/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
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
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.
On 4/17/07, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
If there are another users, then flag should not be set.
depends if there's a 'generic' algo that can be used at the same time.
Admin should know that.
If there are no another users, your code already has exclusive access.
sorry I
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
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
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
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
Francis Moreau <[EMAIL PROTECTED]> wrote:
>
>> > normal version:
>> > test 4 (128 bit key, 8192 byte blocks): 1 operation in 67991 cycles (8192
>> > bytes)
>> >
>> > optimized version:
>> > test 4 (128 bit key, 8192 byte blocks): 1 operation in 51783 cycles (8192
>> > bytes)
>> >
>> > So the gain
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
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 prevent others users
to use this module with priority.
Priority is a stuff that tells
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.
Actually there's nothing really interesting in this code, only key or
acc loadings and that's it.
What do you want to see exactly ?
Thanks
--
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 02:36:09PM +0200, Francis Moreau ([EMAIL PROTECTED])
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
On Tue, Apr 17, 2007 at 02:36:09PM +0200, Francis Moreau ([EMAIL PROTECTED])
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:
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 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
On 4/17/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
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
On Tue, Apr 17, 2007 at 05:34:12PM +0200, Francis Moreau ([EMAIL PROTECTED])
wrote:
Preventing anyone from using the module is incorrect.
How will you handle the case when you have only one algo registered and
it will be exclusively used by ecryptfs?
As I tried to explain, in that case
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
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 4/17/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
If there are another users, then flag should not be set.
depends if there's a 'generic' algo that can be used at the same time.
Admin should know that.
If there are no another users, your code already has exclusive access.
sorry I
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
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 one crypto
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
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, Herbert Xu [EMAIL PROTECTED] wrote:
Actually, I was referring to your AES module :)
Well I don't if I can do that unfortunately.
Actually there's nothing really interesting in this code, only key or
acc loadings and that's it.
What do you want to see exactly ?
Thanks
--
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 prevent others users
to use this module with priority.
Priority is a stuff that tells you
Francis Moreau [EMAIL PROTECTED] wrote:
normal version:
test 4 (128 bit key, 8192 byte blocks): 1 operation in 67991 cycles (8192
bytes)
optimized version:
test 4 (128 bit key, 8192 byte blocks): 1 operation in 51783 cycles (8192
bytes)
So the gain is 16000 cycles which seems to
On Tue, Apr 17, 2007 at 06:18:42PM +0200, Francis Moreau ([EMAIL PROTECTED])
wrote:
If there are no another users, your code already has exclusive access.
sorry I don't understand that.
Since there are no users except your module, you do have exclusive
access already, i.e. you can stop key
On 4/17/07, Roland Dreier [EMAIL PROTECTED] wrote:
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
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 pushed to hardware, and set a flag if it is. Then only do
your set_key() if you have a new key to pass to hardware.
I'm assuming the
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,
On 4/15/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
On Sat, Apr 14, 2007 at 11:10:08PM +0200, Francis Moreau wrote:
>
> 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" ?
What they request
On 4/15/07, Herbert Xu [EMAIL PROTECTED] wrote:
On Sat, Apr 14, 2007 at 11:10:08PM +0200, Francis Moreau wrote:
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 ?
What they request is up to
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
On Sat, Apr 14, 2007 at 11:10:08PM +0200, Francis Moreau wrote:
>
> 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" ?
What they request is up to the administrator.
Cheers,
--
Visit
On Sat, Apr 14, 2007 at 11:10:08PM +0200, Francis Moreau wrote:
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 ?
What they request is up to the administrator.
Cheers,
--
Visit Openswan at
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
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"
Hi,
On 4/14/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
It should be easy to restrict a crypto device so that it's used
by one specific user. That's why we have generic names ("aes") vs.
specific ones ("aes-foo").
So if you let the priority user pick "aes-foo" instead of "aes",
and given that
Hi,
On 4/14/07, Herbert Xu [EMAIL PROTECTED] wrote:
It should be easy to restrict a crypto device so that it's used
by one specific user. That's why we have generic names (aes) vs.
specific ones (aes-foo).
So if you let the priority user pick aes-foo instead of aes,
and given that there is a
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
Francis Moreau <[EMAIL PROTECTED]> wrote:
>
> Crypto core already seems to implement a priority mechanism. But I
> don't think I'm able to say "I'd like to use this algo for encrypting
> filesystems. If another part of the kernel wants to use this algo then
> give it the generic one". This choice
Hi,
On 4/13/07, Helge Hafting <[EMAIL PROTECTED]> wrote:
Francis Moreau wrote:
> So is this interpretation right ? If so wouldn't it be appropriate to
> introduce a mechanism to reserve this AES hardware for a special
> purpose (filesystem encryptions) and thus make it as fast as possible
> ?
>
Francis Moreau wrote:
Hi,
After reading the crypto code and trying to implement a AES driver,
I'm wondering if the current implementation is optimum. My plan is to
use _exclusively_ the AES driver to encrypt filesystems by using
eCryptfs for example.
But it seems that because the current
Francis Moreau wrote:
Hi,
After reading the crypto code and trying to implement a AES driver,
I'm wondering if the current implementation is optimum. My plan is to
use _exclusively_ the AES driver to encrypt filesystems by using
eCryptfs for example.
But it seems that because the current
Hi,
On 4/13/07, Helge Hafting [EMAIL PROTECTED] wrote:
Francis Moreau wrote:
So is this interpretation right ? If so wouldn't it be appropriate to
introduce a mechanism to reserve this AES hardware for a special
purpose (filesystem encryptions) and thus make it as fast as possible
?
Would
Francis Moreau [EMAIL PROTECTED] wrote:
Crypto core already seems to implement a priority mechanism. But I
don't think I'm able to say I'd like to use this algo for encrypting
filesystems. If another part of the kernel wants to use this algo then
give it the generic one. This choice seems
Hi,
After reading the crypto code and trying to implement a AES driver,
I'm wondering if the current implementation is optimum. My plan is to
use _exclusively_ the AES driver to encrypt filesystems by using
eCryptfs for example.
But it seems that because the current implementation of the
Hi,
After reading the crypto code and trying to implement a AES driver,
I'm wondering if the current implementation is optimum. My plan is to
use _exclusively_ the AES driver to encrypt filesystems by using
eCryptfs for example.
But it seems that because the current implementation of the
62 matches
Mail list logo
