The cipher and digest support is at the granularity of nids, and
these combine algorithm, key-length, and mode. So if you implement
support for those cipher,length,mode combinations that can be
accelerated by AES-NI, your engine will only be invoked for those
combinations. You're not obliged to
Implementation aiming to complement interface exposed by crypto/aes/asm
should allow for non-16-byte-aligned key schedule. Period. One can use
movups, or check alignment and choose between movups and movaps code
paths, or copy key schedule to aligned location on stack.
Should it be considered
On Tue, 2008-12-16 at 21:30 +0800, Andy Polyakov wrote:
Implementation aiming to complement interface exposed by crypto/aes/asm
should allow for non-16-byte-aligned key schedule. Period. One can use
movups, or check alignment and choose between movups and movaps code
paths, or copy key
On Tue, 2008-12-16 at 19:12 +0800, Andy Polyakov wrote:
The cipher and digest support is at the granularity of nids, and
these combine algorithm, key-length, and mode. So if you implement
support for those cipher,length,mode combinations that can be
accelerated by AES-NI, your engine will
On Fri, 2008-12-12 at 12:24 +0800, Geoff Thorpe wrote:
On Thursday 11 December 2008 23:02:12 Huang Ying wrote:
On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote:
The cipher and digest support is at the granularity of nids, and
these combine algorithm, key-length, and mode. So if you
Subject:Re: [PATCH RFC] Add support to Intel AES-NI instruction set for
x86_64 platform
On Thursday 11 December 2008 05:04:36 Peter Waltenberg wrote:
Anything in memory could end up swapped out, but stack is the least
likely since it's more often in use, the best you can do is zero the
area ASAP.
My other objection to putting all of this into an engine is that the
engine code
On Thu, Dec 11, 2008 at 10:03:32AM -0500, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in ./crypto/engine/
rather ./engines/) and the intention is that they should be the
implementation de base for those build targets to which they apply.
I'm surprised this can
On Thursday 11 December 2008 10:52:36 Thor Lancelot Simon wrote:
On Thu, Dec 11, 2008 at 10:03:32AM -0500, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in
./crypto/engine/ rather ./engines/) and the intention is that they
should be the implementation de base for
Geoff Thorpe wrote:
...
Caveat: I haven't been involved in FIPS at all BTW, so I find myself
in the couldn't care less category regarding the details. But if
there's something that needs to be locked down (ie. fixed in the C
code), we can surely lock it down as a part *of* the engine code
On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote:
On Thursday 11 December 2008 05:04:36 Peter Waltenberg wrote:
Anything in memory could end up swapped out, but stack is the least
likely since it's more often in use, the best you can do is zero the
area ASAP.
My other objection to
Subject:Re: [PATCH RFC] Add support to Intel AES-NI instruction set for
x86_64 platform
Subject:Re: [PATCH RFC] Add support to Intel AES-NI instruction set for
x86_64 platform
On Thursday 11 December 2008 20:39:41 Huang Ying wrote:
On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in
./crypto/engine/ rather ./engines/) and the intention is that they
should be the implementation de base for those build
On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote:
On Thursday 11 December 2008 20:39:41 Huang Ying wrote:
On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote:
Engines like eng_cryptodev.c *are* built in (they're in
./crypto/engine/ rather ./engines/) and the intention is that they
On Thursday 11 December 2008 23:02:12 Huang Ying wrote:
On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote:
The cipher and digest support is at the granularity of nids, and
these combine algorithm, key-length, and mode. So if you implement
support for those cipher,length,mode
- OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable
for both Unix and Win64;
OK. I will follow the way like that in aes-x86_64.pl to deal with ABI
issue.
Oh! Currently x86_64-xlate.pl doesn't handle 3 operand instructions, so
some SIMD instructions can't be handled. Some
I doubt the OS vendors would bother
to enable an engine by default, testing of the possible
configurations is expensive and the costs of support calls if they
mess up makes autodetecting the engine to use a very unattractive
proposition.
One can discuss loading selected engines by
On Wed, 2008-12-10 at 15:56 +0800, Andy Polyakov wrote:
- and $-16, %rdx is unacceptable in this context. The relevant
interface is exposed to end-user and we have to reserve for possibility
that key schedule is memcpy-ed to location with alternative alignment;
Does there any other
On Wed, 2008-12-10 at 16:01 +0800, Andy Polyakov wrote:
I doubt the OS vendors would bother
to enable an engine by default, testing of the possible configurations is
expensive and the costs of support calls if they mess up makes
autodetecting the engine to use a very unattractive
On Wed, 2008-12-10 at 17:22 +0800, Andy Polyakov wrote:
- OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable
for both Unix and Win64;
OK. I will follow the way like that in aes-x86_64.pl to deal with ABI
issue.
Oh! Currently x86_64-xlate.pl doesn't handle 3 operand
On Wed, 2008-12-10 at 15:56 +0800, Andy Polyakov wrote:
Implementation aiming to complement interface exposed by crypto/aes/asm
should allow for non-16-byte-aligned key schedule. Period. One can use
movups, or check alignment and choose between movups and movaps code
paths, or copy key
As for RFC part. NO! This is NOT the way to do it. For several reasons
(in ascending order of importance):
- OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable
for both Unix and Win64;
- and $-16, %rdx is unacceptable in this context. The relevant
interface is exposed to end-user
:Re: [PATCH RFC] Add support to Intel AES-NI instruction set for
x86_64 platform
As for RFC part. NO! This is NOT the way to do it. For several reasons
(in ascending order
If you want this in the mainstream code, you'll need to detect the
capability at runtime and use your alternate code paths only if the
hardware is present.
He did. It wouldn't work on Win64, but on Unix detection would actually
work.
There are advantages in this being present all the
On Wed, 2008-12-10 at 03:40 +0800, Andy Polyakov wrote:
As for RFC part. NO! This is NOT the way to do it. For several reasons
(in ascending order of importance):
- OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable
for both Unix and Win64;
OK. I will follow the way like
On Wed, 2008-12-10 at 04:58 +0800, Peter Waltenberg wrote:
If you want this in the mainstream code, you'll need to detect the
capability at runtime and use your alternate code paths only if the
hardware is present. It's not even to Intels advantage if OpenSSL crashes
and burns on older Intel
On Wed, 2008-12-10 at 05:47 +0800, Andy Polyakov wrote:
I doubt the OS vendors would bother
to enable an engine by default, testing of the possible configurations is
expensive and the costs of support calls if they mess up makes
autodetecting the engine to use a very unattractive
- and $-16, %rdx is unacceptable in this context. The relevant
interface is exposed to end-user and we have to reserve for possibility
that key schedule is memcpy-ed to location with alternative alignment;
Does there any other mechanism to deal with alignment issue in OpenSSL?
The answer is
I doubt the OS vendors would bother
to enable an engine by default, testing of the possible configurations is
expensive and the costs of support calls if they mess up makes
autodetecting the engine to use a very unattractive proposition.
One can discuss loading selected engines by default, i.e.
30 matches
Mail list logo
