Re: [openssl-users] Checking for AES-NI accelration

[Jakob Bohm]

On 10/08/2016 19:02, Norm Green wrote:
I've been wondering how and when OpenSSL decides whether it can use 
the new aes instructions?  Does it decide at build time or at run time?


If I build on a CPU that supports aes instructions but run on a cpu 
that does not, will bad things happen?  Or is OpenSSL smart enough to 
call functions implemented without aes instructions in that case?




Runtime.  See the file crypto/x86cpuid.pl which gets
converted to compiler-specific assembler source code.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Checking for AES-NI accelration

[Norm Green]

I've been wondering how and when OpenSSL decides whether it can use the 
new aes instructions?  Does it decide at build time or at run time?


If I build on a CPU that supports aes instructions but run on a cpu that 
does not, will bad things happen?  Or is OpenSSL smart enough to call 
functions implemented without aes instructions in that case?


Norm Green

On 8/10/16 06:28, Jan Just Keijser wrote:

Hi,

On 10/08/16 14:25, Nagesh shamnur wrote:


Hi Group,

I am running an application which transfers huge chunks of data every 
second (850Mbps) and the same is secured using openssl. However the 
CPU usage on windows is very high ( ~ 100%). So as a part of the 
analysis, I stumbled upon the information that, when using AES 
encryption, if the underlying hardware is Intel CPU, it can support 
AES-NI instruction set and hence make the crypto processing faster. 
So, I wanted to confirm if the same is enabled in my hardware.


So, I wanted to know how to verify if the run is able to use the 
AES-NI instruction set available in the hardware.


I have built openssl and have ensured enabling the asm in both linux 
and windows build.


For windows, to confirm if AES-NI is enabled, support of tools 
available like truecrypt, CPU-Z and blackbox were used if the same 
was enabled in OS usage. And I found that the same is disabled. Also 
I found in some blogs that the same needs to be enabled in BIOS. When 
checked the BIOS settings, the option was not be found and a BIOS 
update is required to enable the same.


However in linux I was unable to conclude if AES-NI is disabled since 
I didn’t had access to any such tools on linux. I checked "#cpuinfo | 
grep aes" and i was unable to find any line regarding AES-NI. However 
when i run the ./openssl speed -evp aes-128-gcm and 
OPENSSL_ia32cap="~0x202" ./openssl speed -elapsed -evp 
aes-128-gcm i am able to find the difference in speed. So i wanted to 
check how to confirm if my linux build has AES-NI enabled or not?


Environment Information:

CPU: E5-2620 0 @2.0GHz

OS: Windows Server 2008

Linux: Ubuntu 3.11.0-15-generic

Openssl versoin: 1.0.2h


I've got a server with that exact same CPU over here; with openssl 
1.0.2d I see the following results:


$ ./openssl  speed -evp aes-128-gcm
[...]
type 16 bytes 64 bytes256 bytes   1024 bytes 8192 
bytes

aes-128-gcm 184391.41k   465791.06k   689190.61k   .65k 781295.62k

$ OPENSSL_ia32cap=0 ./openssl  speed -evp aes-128-gcm
[...]
type 16 bytes 64 bytes256 bytes   1024 bytes 8192 
bytes
aes-128-gcm  43906.03k49490.24k51037.70k 51554.65k
51699.71k


i.e. with AES-NI disabled performance is about ~15 times less. On this 
CPU turboboost is not working so your numbers maybe slightly different.
Another good way to test whether AES-NI is working is by comparing 
BF-CBC to AES-256-CBC: without AES-NI, BF will be faster. with AES-NI, 
AES will be faster.


HTH,

JJK





-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] output from: dh, dhparam, pkeyparam

[Benjamin Kaduk]

On 08/10/2016 11:00 AM, Jakob Bohm wrote:
> On 08/08/2016 16:51, Benjamin Kaduk wrote:
>> What Rich said, and also note that it's perfectly valid usage of the
>> PEM routines to read one type from a BIO and then go on to read
>> another (potentially different) type from the same BIO, as would
>> happen if they were in the same file concatenated after each other. 
>> So, attempting to peek and see if there was other stuff after the
>> read PEM object would be a strange special case.
>>
> Maybe there should be a general
>   check-no-more-data-in-file(BIO*,bool*bIsPEM)
> routine called from the functions that take a file name as
> argument, open it as a BIO, loads some PEM data and closes
> the BIO, thus giving the caller no opportunity to use (or
> check for) any extra PEM blocks (or DER blocks for DER
> input).

That level of foot-shooting-protection seems overkill to me, though my
opinion doesn't really matter since I'm not on the dev team.

-Ben
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] output from: dh, dhparam, pkeyparam

[Jakob Bohm]

On 08/08/2016 16:51, Benjamin Kaduk wrote:
What Rich said, and also note that it's perfectly valid usage of the 
PEM routines to read one type from a BIO and then go on to read 
another (potentially different) type from the same BIO, as would 
happen if they were in the same file concatenated after each other.  
So, attempting to peek and see if there was other stuff after the read 
PEM object would be a strange special case.



Maybe there should be a general
  check-no-more-data-in-file(BIO*,bool*bIsPEM)
routine called from the functions that take a file name as
argument, open it as a BIO, loads some PEM data and closes
the BIO, thus giving the caller no opportunity to use (or
check for) any extra PEM blocks (or DER blocks for DER
input).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl and floating point

[Jakob Bohm]

(Top posting for consistency in this part of the thread)

Note, however that emulated floating point tends to add code
size and startup overhead even when not called.

Hence the need to compile with an option to not use floating
point at all, at least on platforms that don't have platform-
specific optimizations via hardware floating point (such as
the SSE optimizations for some operations on x86 or the VFP
optimizations on later ARM hardware types).

Rich suggested a "hackish" preprocessor trick, which depends
on no current or future OpenSSL code using floating point in
a way that is seriously broken by that trick.

On 10/08/2016 16:51, Kyle Hamilton wrote:
This is compiler-dependent, and because you didn't specify what 
platform you're targeting or what compiler you're using, there's no 
way for us to provide an answer. Check your compiler's documentation.  
GCC, for example, provides software-emulated floating point for 
platforms without hardware support.  Many other open-source and 
commercial compilers do as well.


On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman >wrote:


We have a platform that does not support floating point
operations.  We discovered that openssl uses floating point in the
random number generator.

Is there any build or compile time flag that uses an alternative
to floating point?



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading engines recursively and crypto engine lock

[Krzysztof Konopko]

On 10 August 2016 at 16:19, Jakob Bohm  wrote:

> On 10/08/2016 15:49, Krzysztof Konopko wrote:
>
>> On 10 August 2016 at 15:31, Jakob Bohm  jb-open...@wisemo.com>>wrote:
>> ​
>> 1. Create a third engine3 which loads both engine1 and engine2
>>   internally (
>> ​​
>> without going through OpenSSL and its locks).
>>   So for example engine3->init calls both engine2->init and
>>   engine1->init.
>>
>>
>> ​I don't understand how engine3 could be initialised ​"
>> ​
>> without going through OpenSSL and its locks
>> ​" as it's OpenSSL taking the lock whenever initialising _every_ engine.
>> Also when I call `ENGINE_init()` (indirectly, somewhere deep inside
>> engine1), the implementation of
>> `ENGINE_init()`
>> ​ takes the engine lock. as well which is the source of the problem.
>>
> engine3 would call engine1 and engine2 without going through
> a call to ENGINE_init(), thus making OpenSSL itself see the
> engine1 and engine2 code as part of engine3 (even though
> engine3 really just calls the functions in engine1 and
> engine2).


​Oh, I see.  engine1 and engine2 would expose individual functions which
engine3 would bound as its engine function own (or use some plumbing to
forward calls to the original functions).  This means engine3 would either
link with engine1 and engine2 libraries or `dlopen()` them.  Or something
like that.  I think I get the idea now.
​


>
> ​
>>
>> 2. engine3 would export/provide all the methods from engine1
>>   and engine2 by forwarding or reexporting the calls.
>>
>> 3. OpenSSL itself is instructed to use only your engine3
>>   wrapper.
>>
>> 4. As a more ambitious project, someone could write a generic
>>   "engine3" which loads a list of actual engines from a config
>>   file.
>>
>> At the OpenSSL design level, the OpenSSL team might extend the
>> OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a
>> colon-separatedlist of engines rather than just a single engine.
>>
>>
>>
>> ​That sounds interesting but engines in general (and specifically in my
>> case) are independent of each other and in different situations I may want
>> to load one but not the other (for example when testing).  But I guess that
>> would be a matter of moving the configuration control from where I have it
>> now into whatever mechanism OpenSSL could have (as proposed above).
>>
> The idea would be that "engine3" would be a workaround engine
> that simulates the (possibly missing) ability to specify
> multiple engines via the OPENSSL_SSL_CLIENT_ENGINE_AUTO
> variable.  This not-independent engine3 would do nothing but
> load other engines, and may or may not be configurable as to
> which real engines it loads.  By doing this, engine3 would also
> compensate for the fact that many other OpenSSL APIs seem to
> allow only a single engine reference as parameter.
>
> With engine3 responsible for initializing engine2 before engine1,
> engine1 would no longer contain code to load engine2, making
> engine1 more independent from engine2.
>
>
>
>
​OK, fair enough.  That makes sense.  In my case some re-factoring would be
required as the code that initialises engine2 does so explicitly with
`ENGINE_by_id()` and `ENGINE_init()` and it doesn't "know" it's called from
engine1.  And vice versa, engine1 does not know that the code it calls
loads and initialises an engine.  But I get the idea and it seems plausible.

Also it's important to me that this way or the other there's someone who
admits OpenSSL has a problem with loading engines recursively (or does not
support that intentionally) and I need to address that.

Thanks again!
Kris​
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl and floating point

[Kyle Hamilton]

This is compiler-dependent, and because you didn't specify what platform
you're targeting or what compiler you're using, there's no way for us to
provide an answer.  Check your compiler's documentation.  GCC, for example,
provides software-emulated floating point for platforms without hardware
support.  Many other open-source and commercial compilers do as well.

-Kyle H


On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman 
wrote:

> We have a platform that does not support floating point operations.  We
> discovered that openssl uses floating point in the random number generator.
>
> Is there any build or compile time flag that uses an alternative to
> floating point?
>
> --
> Ken Goldman   kgold...@us.ibm.com
> 914-945-2415 (862-2415)
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Openssl and floating point

[Salz, Rich]

> We have a platform that does not support floating point operations.  We 
> discovered that openssl uses floating point in the random number generator.

There are other places, too, like bio_print, the poly135 code, etc.  Good 
luck...

> Is there any build or compile time flag that uses an alternative to floating 
> point?
-Ddouble=long
? :)
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading engines recursively and crypto engine lock

[Jakob Bohm]

On 10/08/2016 15:49, Krzysztof Konopko wrote:
On 10 August 2016 at 15:31, Jakob Bohm >wrote:


I am not part of the OpenSSL team and have no idea what their
thinking or suggestions are.


​Thanks for responding!
​


However the following should be a generic workaround:

1. Create a third engine3 which loads both engine1 and engine2
  internally (
​​
without going through OpenSSL and its locks).
  So for example engine3->init calls both engine2->init and
  engine1->init.


​I don't understand how engine3 could be initialised ​"
​
without going through OpenSSL and its locks
​" as it's OpenSSL taking the lock whenever initialising _every_ 
engine.  Also when I call `ENGINE_init()` (indirectly, somewhere deep 
inside engine1), the implementation of

`ENGINE_init()`
​ takes the engine lock. as well which is the source of the problem.

engine3 would call engine1 and engine2 without going through
a call to ENGINE_init(), thus making OpenSSL itself see the
engine1 and engine2 code as part of engine3 (even though
engine3 really just calls the functions in engine1 and
engine2).

​

2. engine3 would export/provide all the methods from engine1
  and engine2 by forwarding or reexporting the calls.

3. OpenSSL itself is instructed to use only your engine3
  wrapper.

4. As a more ambitious project, someone could write a generic
  "engine3" which loads a list of actual engines from a config
  file.

At the OpenSSL design level, the OpenSSL team might extend the
OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a
colon-separatedlist of engines rather than just a single engine.



​That sounds interesting but engines in general (and specifically in 
my case) are independent of each other and in different situations I 
may want to load one but not the other (for example when testing).  
But I guess that would be a matter of moving the configuration control 
from where I have it now into whatever mechanism OpenSSL could have 
(as proposed above).

The idea would be that "engine3" would be a workaround engine
that simulates the (possibly missing) ability to specify
multiple engines via the OPENSSL_SSL_CLIENT_ENGINE_AUTO
variable.  This not-independent engine3 would do nothing but
load other engines, and may or may not be configurable as to
which real engines it loads.  By doing this, engine3 would also
compensate for the fact that many other OpenSSL APIs seem to
allow only a single engine reference as parameter.

With engine3 responsible for initializing engine2 before engine1,
engine1 would no longer contain code to load engine2, making
engine1 more independent from engine2.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Checking for AES-NI accelration

[Jan Just Keijser]

Hi,

On 10/08/16 14:25, Nagesh shamnur wrote:


Hi Group,

I am running an application which transfers huge chunks of data every 
second (850Mbps) and the same is secured using openssl. However the 
CPU usage on windows is very high ( ~ 100%). So as a part of the 
analysis, I stumbled upon the information that, when using AES 
encryption, if the underlying hardware is Intel CPU, it can support 
AES-NI instruction set and hence make the crypto processing faster. 
So, I wanted to confirm if the same is enabled in my hardware.


So, I wanted to know how to verify if the run is able to use the 
AES-NI instruction set available in the hardware.


I have built openssl and have ensured enabling the asm in both linux 
and windows build.


For windows, to confirm if AES-NI is enabled, support of tools 
available like truecrypt, CPU-Z and blackbox were used if the same was 
enabled in OS usage. And I found that the same is disabled. Also I 
found in some blogs that the same needs to be enabled in BIOS. When 
checked the BIOS settings, the option was not be found and a BIOS 
update is required to enable the same.


However in linux I was unable to conclude if AES-NI is disabled since 
I didn’t had access to any such tools on linux. I checked "#cpuinfo | 
grep aes" and i was unable to find any line regarding AES-NI. However 
when i run the ./openssl speed -evp aes-128-gcm and 
OPENSSL_ia32cap="~0x202" ./openssl speed -elapsed -evp 
aes-128-gcm i am able to find the difference in speed. So i wanted to 
check how to confirm if my linux build has AES-NI enabled or not?


Environment Information:

CPU: E5-2620 0 @2.0GHz

OS: Windows Server 2008

Linux: Ubuntu 3.11.0-15-generic

Openssl versoin: 1.0.2h


I've got a server with that exact same CPU over here; with openssl 
1.0.2d I see the following results:


$ ./openssl  speed -evp aes-128-gcm
[...]
type 16 bytes 64 bytes256 bytes   1024 bytes 8192 bytes
aes-128-gcm 184391.41k   465791.06k   689190.61k   .65k 781295.62k

$ OPENSSL_ia32cap=0 ./openssl  speed -evp aes-128-gcm
[...]
type 16 bytes 64 bytes256 bytes   1024 bytes 8192 bytes
aes-128-gcm  43906.03k49490.24k51037.70k51554.65k 51699.71k

i.e. with AES-NI disabled performance is about ~15 times less. On this 
CPU turboboost is not working so your numbers maybe slightly different.
Another good way to test whether AES-NI is working is by comparing 
BF-CBC to AES-256-CBC: without AES-NI, BF will be faster. with AES-NI, 
AES will be faster.


HTH,

JJK

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading engines recursively and crypto engine lock

[Krzysztof Konopko]

On 10 August 2016 at 15:31, Jakob Bohm  wrote:

> I am not part of the OpenSSL team and have no idea what their
> thinking or suggestions are.
>

​Thanks for responding!
​


>
> However the following should be a generic workaround:
>
> 1. Create a third engine3 which loads both engine1 and engine2
>   internally (
> ​​
> without going through OpenSSL and its locks).
>   So for example engine3->init calls both engine2->init and
>   engine1->init.
>
>
​I don't understand how engine3 could be initialised ​"
​
without going through OpenSSL and its locks
​" as it's OpenSSL taking the lock whenever initialising _every_ engine.
Also when I call `ENGINE_init()` (indirectly, somewhere deep inside
engine1), the implementation of
`ENGINE_init()`
​ takes the engine lock. as well which is the source of the problem.
​

> 2. engine3 would export/provide all the methods from engine1
>   and engine2 by forwarding or reexporting the calls.
>
> 3. OpenSSL itself is instructed to use only your engine3
>   wrapper.
>
> 4. As a more ambitious project, someone could write a generic
>   "engine3" which loads a list of actual engines from a config
>   file.
>
> At the OpenSSL design level, the OpenSSL team might extend the
> OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a
> colon-separatedlist of engines rather than just a single engine.
>
>
>
​That sounds interesting but engines in general (and specifically in my
case) are independent of each other and in different situations I may want
to load one but not the other (for example when testing).  But I guess that
would be a matter of moving the configuration control from where I have it
now into whatever mechanism OpenSSL could have (as proposed above).

Thanks,
Kris​
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Loading engines recursively and crypto engine lock

[Jakob Bohm]

On 08/08/2016 13:39, Krzysztof Konopko wrote:

Hi,

TL;DR;
Is it allowed to initialise engines recursively, ie. call 
`engine2->init` from `engine1->init`?


--

I have a solution in a consumer product based on OpenSSL 1.0.2 series 
that uses two engines: one (engine1) for selecting client certificate 
chain (TLS client auth) and another one (engine2) for RPC operations 
on associated private keys stored in H/W.  This works only if supplied 
(installed) locks are recursive as for each engine initialisation 
`CRYPTO_LOCK_ENGINE` is taken.


From what I see, OpenSSL 1.1.x onward, provides locking internally and 
it's non-recursive.  Also `lock_dbg_cb()` implementation in OpenSSL 
before 1.1.x suggests locks are not expected to be recursive.


Here's some more context of my use case.​

OpenSSL loads `engine1` for me automatically (`
​​
​
OPENSSL_SSL_CLIENT_ENGINE_AUTO` variable) which is convenient as I 
don't have control over application's `main()` function.  In my case 
it's proprietary code but equally it could be Python script (I do not 
fancy patching Python interpreter to get to its `main()` function and 
load/initialise engines explicitly).


So my _only_ entry point is `engine1->init`.  In that entry point I 
initialise engine2 which is a fairly slow operation (need to load 
certs from permanent storage) so definitely want to do this only once. 
Oh, and the app is heavily multi-threaded so I'm glad OpenSSL 
carefully takes crypto engine lock where needed.


But because engines are initialised recursively, the locking 
implementation I supply uses recursive mutex which works very well and 
makes perfect sense to me in this case (I know that the same thread 
calls locked functions recursively for a reason).  This works only 
before 1.1.x.


Alternatively I could lazy-initialise engine2 in certificate callback 
function but any initialisation failure here would be less meaningful 
and it would require another lock to protect engine2 handle.  In 
`engine1->init` I know a lock is already held so I thought it's safer 
to do more initialisation here.  Besides `engine2->init` is not called 
directly but through a layer of application logic so conceptually 
these two engines are orthogonal and know nothing about each other.


I guess initialising engines recursively does not work in OpenSSL 
1.1.x (it'd be a dead-lock) and I need to seek for a different place 
to initialise engine2, for example in certificate cb?  This would mean 
I "leak" some knowledge of engine2 existence into engine1, have 
guarantee that crypto engine lock is not held in certificate callabck 
function and need another lock to protect access to engine2 handle.


Please let me know what your views are and if the above makes sense.


I am not part of the OpenSSL team and have no idea what their
thinking or suggestions are.

However the following should be a generic workaround:

1. Create a third engine3 which loads both engine1 and engine2
  internally (without going through OpenSSL and its locks).
  So for example engine3->init calls both engine2->init and
  engine1->init.

2. engine3 would export/provide all the methods from engine1
  and engine2 by forwarding or reexporting the calls.

3. OpenSSL itself is instructed to use only your engine3
  wrapper.

4. As a more ambitious project, someone could write a generic
  "engine3" which loads a list of actual engines from a config
  file.

At the OpenSSL design level, the OpenSSL team might extend the
OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a
colon-separatedlist of engines rather than just a single engine.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Openssl and floating point

[Kenneth Goldman]

We have a platform that does not support floating point operations.  We 
discovered that openssl uses floating point in the random number 
generator.

Is there any build or compile time flag that uses an alternative to 
floating point?

--
Ken Goldman   kgold...@us.ibm.com 
914-945-2415 (862-2415)




-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Info Request

[Jakob Bohm]

On 09/08/2016 19:26, Luiggi Valles wrote:



Helo.

I'm trying to used OPENSSL to generate a sign XDAS-BES with PHP
and I have some problem but the most important is the function exec().

I would like to know howI do that: the exec () function does not
block the function of OpenSSL?

Can you please tell me more about this? Please.


Please clarify: Are you using generic PHP calls to run the
"openssl" command line program, or are you using a PHP
extension that wraps OpenSSL calls (and if so, which one).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Checking for AES-NI accelration

[Nagesh shamnur]

Hi Group,

I am running an application which transfers huge chunks of data 
every second (850Mbps) and the same is secured using openssl. However the CPU 
usage on windows is very high ( ~ 100%). So as a part of the analysis, I 
stumbled upon the information that, when using AES encryption, if the 
underlying hardware is Intel CPU, it can support AES-NI instruction set and 
hence make the crypto processing faster. So, I wanted to confirm if the same is 
enabled in my hardware.

So, I wanted to know how to verify if the run is able to use the 
AES-NI instruction set available in the hardware.

I have built openssl and have ensured enabling the asm in both 
linux and windows build.



For windows, to confirm if AES-NI is enabled, support of tools 
available like truecrypt, CPU-Z and blackbox were used if the same was enabled 
in OS usage. And I found that the same is disabled. Also I found in some blogs 
that the same needs to be enabled in BIOS. When checked the BIOS settings, the 
option was not be found and a BIOS update is required to enable the same.



However in linux I was unable to conclude if AES-NI is disabled since I didn’t 
had access to any such tools on linux. I checked "#cpuinfo | grep aes" and i 
was unable to find any line regarding AES-NI. However when i run the ./openssl 
speed -evp aes-128-gcm and OPENSSL_ia32cap="~0x202" ./openssl speed 
-elapsed -evp aes-128-gcm i am able to find the difference in speed. So i 
wanted to check how to confirm if my linux build has AES-NI enabled or not?




Environment Information:

CPU: E5-2620 0 @2.0GHz

OS: Windows Server 2008

Linux: Ubuntu 3.11.0-15-generic

Openssl versoin: 1.0.2h

Mainboard: Manufacturer Huawei Technologies Co. Ltd., Model: BC11SRSH1 V100R002

BIOS: Brand: INsyde Corp, RMISV061, 06/20/2013


Regards,
Nagesh.



华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Certificates generated using 3k/4k CSR generated with OpenSSL fails on Windows 2008R2

[Jayalakshmi bhat]

Hi All,

I am generating 1k/2k/3k/4k CSR's on our device using OpenSSL library. I am
generating these CSR on our device. We have windows 2008 R2 servers and I
am signing these CSR using certificate authority on windows server.  I am
 setting only client and server authentication bits in the CSR since these
are simple end entity certificates. Once certificates are generated , I am
 able to install the certificates on our device.

These certificates are working well with 802.1x (EAP-TLS) setup on the same
windows 2008 R2 server. However when I was trying to test IPsec with
certificate based authentication, authentication is failing.Enabling the
IPsec event viewer shows error in accepting the certificate and generates a
?invalid signature? message which looks to be generic. Failures are seen
only with 3k and 4k certificates.

Later I  refered to a link http://blog.gentilkiwi.com/tag/bag-attributes
added
 -LMK -CSP "xxx" -name options, certificate worked well. I wanted to know
is any one having similar experience with 3k and 4k ID certificates that
does not have these fields on windows system.

Any help is appreciated.

Regards
Jayalakshmi
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users