On Fri, Aug 17, 2007 at 11:23:14AM +0800, Herbert Xu wrote:
> On Sun, Aug 12, 2007 at 03:11:30PM +, Hye-Shik Chang wrote:
> > Hello,
> >
> > Here I propose a patch for linux crypto API to add a support SEED
> > (RFC4269). This patch was generated against git-HEAD as of today.
> > This patch h
Joy Latten <[EMAIL PROTECTED]> wrote:
>>
>>The salt will just come from the key field. So instead of having
>>an 128-bit key for example, you'd have 152 bits.
>
> ok, quick question, this 152 bits key will be part
> of input to setkey()?
Yes.
> The reason I am asking is because setkey in ablkc
>
>The salt will just come from the key field. So instead of having
>an 128-bit key for example, you'd have 152 bits.
ok, quick question, this 152 bits key will be part
of input to setkey()?
The reason I am asking is because setkey in ablkcipher and
blkcipher check key length for min and max siz
On Mon, Aug 20, 2007 at 03:06:39PM +0200, Andi Kleen wrote:
>
> > Well it's not that useful for an assembly implementation
> > that works on all instances of a given architecture.
>
> I meant on x86. Sure for other architectures the C version is needed.
My point was that while it's not useful for
> That would be the best. However, it's not hard to do a
> simple probing in the kernel until modprobe(8) gets this
> feature.
Sounds like a big hack, and at least for aes / aes-x86_64 and
twofish it's not needed. Just disable aes on x86.
The only problem is the select issue with wireless.
Unf
On Mon, Aug 20, 2007 at 12:16:18PM +0200, Andi Kleen wrote:
>
> The usual use case is: Somebody -- either admin or some command
> implicitely -- executes modprobe aes because some text file
> specifies the aes cipher. At least on my system that loads
> the C version when both are enabled. modprob
* Andi Kleen | 2007-08-20 13:12:39 [+0200]:
>I'm thinking of standard distribution kernel users though. They
>just want to tell some high level configuration they want aes
>(or twofish) and expect the most efficient implementation
>to be loaded automatically.
Sure.
>The distribution kernel coul
On Mon, Aug 20, 2007 at 12:08:19PM +0200, Sebastian Siewior wrote:
> * Andi Kleen | 2007-08-20 12:47:14 [+0200]:
>
> >> Not modprobe, but the crypto subsystem. If you have the generic C code
> >> and the assembly variant it picks the assembly over C. The selection is
> >
> >But only if they're bot
* Andi Kleen | 2007-08-20 12:47:14 [+0200]:
>> Not modprobe, but the crypto subsystem. If you have the generic C code
>> and the assembly variant it picks the assembly over C. The selection is
>
>But only if they're both loaded. Who loads both?
In my case I do. I have the assembly version compile
> Not modprobe, but the crypto subsystem. If you have the generic C code
> and the assembly variant it picks the assembly over C. The selection is
But only if they're both loaded. Who loads both?
> In that case yes. Would it help to add MODULE_ALIAS("aes") to the
> assembly version in order to l
* Andi Kleen | 2007-08-20 12:16:18 [+0200]:
>> Are you sure you get the C version when both are built-in
>> or loaded as modules? If so then we have a bug in the priority
>> code.
>
>The usual use case is: Somebody -- either admin or some command
>implicitely -- executes modprobe aes because some
> Are you sure you get the C version when both are built-in
> or loaded as modules? If so then we have a bug in the priority
> code.
The usual use case is: Somebody -- either admin or some command
implicitely -- executes modprobe aes because some text file
specifies the aes cipher. At least on my
12 matches
Mail list logo
