Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Licensing issues are indeed thorny. Why can't openssl perform a dynamic
link? The soversion should handle any ABI issues introduced in later
versions of GMP.

Are you cross compiling GMP for your use on a target device? If so, you'll
need to ensure that the MPN_PATH is set appropriately. If you don't do so,
you'll get the generic c code instead of optimized assembly routines. The
performance difference can be dramatic, potentially several orders of
magnitude. I had to deal with this myself when cross compiling GMP for
Android.

On Feb 7, 2017 4:51 PM, "Vijay Chander"  wrote:

Yes. Already took Andy's word from his previous replies for precisely this
reason.

GMP exercise was easy enough to get it out of the way.

Thanks,
Vijay

On Feb 7, 2017 4:46 PM, "Jakob Bohm"  wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> 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 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] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Yes. Already took Andy's word from his previous replies for precisely this
reason.

GMP exercise was easy enough to get it out of the way.

Thanks,
Vijay

On Feb 7, 2017 4:46 PM, "Jakob Bohm"  wrote:

> OpenSSL also has a lot of handwritten assembly language for ARM,
> x86 etc.  Most of it written by Andy Polyakov.
>
> His response about what can and cannot be done on various ARM CPU
> models is most probably a result of this work.
>
> Also, OpenSSL has a more permissive license than the GMP, so using
> GMP in OpenSSL would cause problems for many OpenSSL using
> applications.
>
> On 08/02/2017 00:31, Mike Mohr wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code
>> and the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander" > > wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a
>> lower priority).
>>
>> Thanks,
>> -vijay
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > > wrote:
>>
>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should
>> hopefully
>> > get down to -1:5.
>>
>> And Mongoose will take you to ~1:2.5 (scaled to same frequency
>> that is).
>> Which I'd say is a fair result. Well, still could have been a bit
>> better, but it's not unreasonable given ISA differences. Keep
>> in mind
>> that presented x86_64 result is for code utilizing
>> Intel-specific code
>> extensions.
>>
>> > There is no L3 cache on the A72 eval board and performance
>> counters do
>> > show 9x more DRAM accesses for ARM compared to x86.
>>
>> This is unexpected, because it takes *less* references to
>> memory to
>> perform it on ARMv8. Because it has larger register bank. And
>> cache
>> requirement is not that high for L3 to kick in... But at any
>> case memory
>> is not bottleneck here...
>>
>>
>
> --
> Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
> Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10  +4531131610>
> This message is only for its intended recipient, delete if misaddressed.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> 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 mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Jakob Bohm]

OpenSSL also has a lot of handwritten assembly language for ARM,
x86 etc.  Most of it written by Andy Polyakov.

His response about what can and cannot be done on various ARM CPU
models is most probably a result of this work.

Also, OpenSSL has a more permissive license than the GMP, so using
GMP in OpenSSL would cause problems for many OpenSSL using
applications.

On 08/02/2017 00:31, Mike Mohr wrote:

Have you considered using GMP as a big integer backed for openssl?  It
has support for several arm variants using handwritten assembly code
and the developers go to great lengths to find optimize runtime on all
supported platforms.

On Feb 7, 2017 2:26 PM, "Vijay Chander" > wrote:

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a
lower priority).

Thanks,
-vijay


On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov > wrote:

> A72 is running 1GHz compared to x86 at 2.1Ghz. So that should 
hopefully
> get down to -1:5.

And Mongoose will take you to ~1:2.5 (scaled to same frequency
that is).
Which I'd say is a fair result. Well, still could have been a bit
better, but it's not unreasonable given ISA differences. Keep
in mind
that presented x86_64 result is for code utilizing
Intel-specific code
extensions.

> There is no L3 cache on the A72 eval board and performance
counters do
> show 9x more DRAM accesses for ARM compared to x86.

This is unexpected, because it takes *less* references to
memory to
perform it on ARMv8. Because it has larger register bank. And
cache
requirement is not that high for L3 to kick in... But at any
case memory
is not bottleneck here...




--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 


This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded


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] BN_MUL_MONT for ARM64 v8

[Salz, Rich via openssl-users]

> Have you considered using GMP as a big integer backed for openssl?  It has 
> support for several arm variants using handwritten assembly code and the 
> developers go to great lengths to find optimize runtime on all supported 
> platforms.

It might be interesting if we could figure out how to handle it as a dynamic 
library.  License issues prevent anything else.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Mike,
   Tried with GMP. Same result for A72.

   Thanks,
Vijay

On Tue, Feb 7, 2017 at 3:31 PM, Mike Mohr  wrote:

> Have you considered using GMP as a big integer backed for openssl?  It has
> support for several arm variants using handwritten assembly code and the
> developers go to great lengths to find optimize runtime on all supported
> platforms.
>
> On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:
>
>> Have you considered using GMP as a big integer backed for openssl?  It
>> has support for several arm variants using handwritten assembly code and
>> the developers go to great lengths to find optimize runtime on all
>> supported platforms.
>>
>> On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:
>>
>> Andy,
>>1:2.5 is pretty in my opinion for ARM !
>>
>>We  will check out Mongoose.
>>
>>Hmm - will try to get to the bottom of those cache misses (at a lower
>> priority).
>>
>> Thanks,
>> -vijay
>>
>>
>>
>> On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:
>>
>>> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
>>> > get down to -1:5.
>>>
>>> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
>>> Which I'd say is a fair result. Well, still could have been a bit
>>> better, but it's not unreasonable given ISA differences. Keep in mind
>>> that presented x86_64 result is for code utilizing Intel-specific code
>>> extensions.
>>>
>>> > There is no L3 cache on the A72 eval board and performance counters do
>>> > show 9x more DRAM accesses for ARM compared to x86.
>>>
>>> This is unexpected, because it takes *less* references to memory to
>>> perform it on ARMv8. Because it has larger register bank. And cache
>>> requirement is not that high for L3 to kick in... But at any case memory
>>> is not bottleneck here...
>>>
>>> --
>>> 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
>>
>>
>>
>> --
>> 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] BN_MUL_MONT for ARM64 v8

[Mike Mohr]

Have you considered using GMP as a big integer backed for openssl?  It has
support for several arm variants using handwritten assembly code and the
developers go to great lengths to find optimize runtime on all supported
platforms.

On Feb 7, 2017 2:26 PM, "Vijay Chander"  wrote:

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a lower
priority).

Thanks,
-vijay



On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:

> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> > get down to -1:5.
>
> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
> Which I'd say is a fair result. Well, still could have been a bit
> better, but it's not unreasonable given ISA differences. Keep in mind
> that presented x86_64 result is for code utilizing Intel-specific code
> extensions.
>
> > There is no L3 cache on the A72 eval board and performance counters do
> > show 9x more DRAM accesses for ARM compared to x86.
>
> This is unexpected, because it takes *less* references to memory to
> perform it on ARMv8. Because it has larger register bank. And cache
> requirement is not that high for L3 to kick in... But at any case memory
> is not bottleneck here...
>
> --
> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Andy,
   1:2.5 is pretty in my opinion for ARM !

   We  will check out Mongoose.

   Hmm - will try to get to the bottom of those cache misses (at a lower
priority).

Thanks,
-vijay



On Tue, Feb 7, 2017 at 11:07 AM, Andy Polyakov  wrote:

> > A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> > get down to -1:5.
>
> And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
> Which I'd say is a fair result. Well, still could have been a bit
> better, but it's not unreasonable given ISA differences. Keep in mind
> that presented x86_64 result is for code utilizing Intel-specific code
> extensions.
>
> > There is no L3 cache on the A72 eval board and performance counters do
> > show 9x more DRAM accesses for ARM compared to x86.
>
> This is unexpected, because it takes *less* references to memory to
> perform it on ARMv8. Because it has larger register bank. And cache
> requirement is not that high for L3 to kick in... But at any case memory
> is not bottleneck here...
>
> --
> 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] FW: problem with missing STDINT.H file

[Salz, Rich via openssl-users]

> It's cargo-cult programming, most often by people who can't be bothered to
> learn the language they're using.

There are also sometimes portability issues, vendors get things wrong.

But at any rate, for this project, OpenSSL style says parens after sizeof and 
says nothing at all about pre-processor defined operator. It probably should, 
but clearly our existing style uses parens.

Ok?

You guys are both important contributors to the project.  It hurts me to see 
you fight :)

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

Re: [openssl-users] FW: problem with missing STDINT.H file

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jakob Bohm
> Sent: Tuesday, February 07, 2017 13:37
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] FW: problem with missing STDINT.H file
> 
> Using parenthesis with the defined and sizeof operators is
> considered good for readability and thus proper style in
> most projects.

Rubbish.  Cite a methodologically sound study that shows it improves 
readability, or that "most projects" define it as "proper style". (Good luck 
with the latter, since I'm willing to wager the vast majority of C source isn't 
associated with any explicit style document.)

It's cargo-cult programming, most often by people who can't be bothered to 
learn the language they're using.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Andy Polyakov]

> A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully
> get down to -1:5.

And Mongoose will take you to ~1:2.5 (scaled to same frequency that is).
Which I'd say is a fair result. Well, still could have been a bit
better, but it's not unreasonable given ISA differences. Keep in mind
that presented x86_64 result is for code utilizing Intel-specific code
extensions.

> There is no L3 cache on the A72 eval board and performance counters do
> show 9x more DRAM accesses for ARM compared to x86.

This is unexpected, because it takes *less* references to memory to
perform it on ARMv8. Because it has larger register bank. And cache
requirement is not that high for L3 to kick in... But at any case memory
is not bottleneck here...

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

Re: [openssl-users] How to disable the DTLS stuff in openssl 1.0.2k

[Matt Caswell]

On 06/02/17 09:58, Devang Kubavat wrote:
> Hi,
> I am trying to configure the OpenSSL 1.0.2k for windows.
> Can anyone help me How to disable the DTLS?

I guess this email got stuck somewhere because I only just got this. See
my answer to this on your stackoverflow question:

https://stackoverflow.com/questions/42081976/how-to-disable-the-dtls-stuff-in-openssl-1-0-2k/

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

Re: [openssl-users] FW: problem with missing STDINT.H file

[Jakob Bohm]

On 07/02/2017 17:03, Michael Wojcik wrote:

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
Of Andy Polyakov
Sent: Tuesday, February 07, 2017 10:49

# elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L)

|| \

  defined(__osf__) || defined(__sgi) || defined(__hpux) || \
  defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__)

It should probably be noted that this is quite counter-intuitive
condition.

Also, that "defined(__STDC_VERSION__)" is redundant; if X is not defined in a #if 
test, then it has to be replaced with 0, which is not >= 199901L. Any implementation that 
doesn't do that isn't even compatible with C90, and you'll have bigger problems.

And the "defined" operator is an operator, not a function. The parentheses are 
superfluous.

Using parenthesis with the defined and sizeof operators is
considered good for readability and thus proper style in
most projects.

What is a lot less readable in the if/ifelse/endif block that
was posted is the somewhat counter intuitive order in which
conditions are checked (and thus override each other).  That kind
of complex logic often would benefit from comments clarifying the
reasoning.  For example why is the workaround for UEFI located
before tests for compiler support?  And why are all compilers
claiming compliance with recent STDC versions assumed NOT to
have stdint.h, only inttypes.h?

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] BN_MUL_MONT for ARM64 v8

[Vijay Chander]

Thanks Andy.

A72 is running 1GHz compared to x86 at 2.1Ghz. So that should hopefully get
down to -1:5.
There is no L3 cache on the A72 eval board and performance counters do show
9x more DRAM accesses for ARM compared to x86.

Will check out Mongoose and Kyro.

Do you know of any good hardware crypto intellectual property like synopsis
for example which can help in asymmetric crypto part of TLS handshake ?

Thanks,

Vijay


On Feb 7, 2017 7:06 AM, "Andy Polyakov"  wrote:

>   Is big number montogomery multiplication as optimized as it can be for
> ARM64 as compared to X86-64 from the latest openssl github ?
>   We are not seeing vmull ( or pmull/pmull2) instructions in
> armv8-mont.pl .
>
>On an ARM cortex-A72 (1GHz)  and E5-2620 (2.1 Ghz)  we are seeing an
> order of 10 difference in RSA signing perf for 2048 bit keys.

When it comes to performance correct question actually is not what is
the result in absolute terms, but how far is it from possible maximum
for specific processor [taking into consideration all the factors from
ISA capabilities and specific hardware implementation]. So that implying
that 10x difference between processors in question is result of
insufficient optimization for one is somewhat unjustified. Well, to be
completely honest there are some minor tricks one can pull on ARMv8, but
it will only make the gap a *little* bit smaller. Or in other words suck
it up, that's the way Cortex [currently?] is. If it's so critical *and*
you're in position to choose processor, then Samsung Mongoose core would
be much better choice (but I don't know anything about Qualcomm Kryo).
Yet, even though it would be better choice, it still wouldn't actually
close the gap, so don't get your hopes too high :-)

As for not seeing vector instructions. Pmull[2] is about something
completely different. As for vmull you have to recognize that it's
limited by 32-bit inputs and there is no carry handling in vector
instructions. This means that it would take more instructions to do same
job, even though you perform pair of multiplications in one vector
instruction. Well, it's more complicated than just amount of
instructions, but nevertheless, scalar 64x64 multiplication with carry
processing offered by ARMv8 ISA does deliver better result than 128-bit
vector instructions would.

--
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] FW: problem with missing STDINT.H file

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Andy Polyakov
> Sent: Tuesday, February 07, 2017 10:49
> > # elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L)
> || \
> >  defined(__osf__) || defined(__sgi) || defined(__hpux) || \
> >  defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__)
> 
> It should probably be noted that this is quite counter-intuitive
> condition.

Also, that "defined(__STDC_VERSION__)" is redundant; if X is not defined in a 
#if test, then it has to be replaced with 0, which is not >= 199901L. Any 
implementation that doesn't do that isn't even compatible with C90, and you'll 
have bigger problems.

And the "defined" operator is an operator, not a function. The parentheses are 
superfluous.

# elif __STDC_VERSION__ >= 199901L || \
  defined __osf__ || defined __sgi || defined __hpux || \
  defined OPENSSL_SYS_VMS || defined __OpenBSD__ || defined __sun
  /* C99 implementations and some others have inttype.h */

Ah, that's almost readable.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



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

Re: [openssl-users] FW: problem with missing STDINT.H file

[Andy Polyakov]

>> The attached text file is a snippet from attempting to install
>> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when
>>  could not be found.
> 
> Do you have inttypes.h instead?
> 
> As Jeff pointed out in another email this is for uint32_t and similar
> types. These get included from e_os2.h as follows:
> 
> # if defined(OPENSSL_SYS_UEFI)
> typedef INT8 int8_t;
> typedef UINT8 uint8_t;
> typedef INT16 int16_t;
> typedef UINT16 uint16_t;
> typedef INT32 int32_t;
> typedef UINT32 uint32_t;
> typedef INT64 int64_t;
> typedef UINT64 uint64_t;
> #  define PRIu64 "%Lu"
> # elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
>  defined(__osf__) || defined(__sgi) || defined(__hpux) || \
>  defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__)
> #  include 

It should probably be noted that this is quite counter-intuitive
condition. Basically all those defined(__this-or-that__) refer to
systems that are kind of stuck between standards and are "almost, but
not quite, entirely unlike" 199901L. So that intuitively one would
expect to see __STDC_VERSION__ < 199901L || defined(__this-or-that__).
But then it was argued that inttypes.h >= 199901L includes stdint.h
anyway, as well as defines other "goodies". So that this condition
effectively produces two different outcomes: on >=199901L it results in
*extended* equivalent of stdint.h, and on __this-n-that__ - in
*pre-standard*, potentially limited equivalent of stdint.h. And
remaining question in the context of original query is what is Solaris
8. It does have inttypes.h so that one can [and probably should] extend
__this-or-that__ with defined(__sun). [And as Jeffrey already mentioned
compiling OpenSSL is job for C compiler, not C++.]

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

[openssl-users] Doubt regarding process of invalid [D]TLS record

[Raja ashok]

Hi All,

In dtls1_get_record(), we are calling ssl3_read_n to get 13 bytes of DTLS 
record header from socket and then based on the length in record header, we 
again call ssl3_read_n to get record payload from socket. Here we are handling 
invalid record, like length less 13 bytes or invalid version in record header 
or invalid epoch etc. If such invalid record comes then we are dropping that 
record and going to read again from socket, by calling ssl3_read_n again. If a 
peer is continuously sending invalid DTLS record, then our execution will be 
just running inside dtls1_get_record function. It wont come out of that 
function. So if a malicious peer wants to block our DTLS connection thread, 
then it can do by simply sending invalid DTLS record continuously. This 
behaviour would be same for both synchronous and asynchronous UDP sockets. This 
will simply block the application for long time, for the API SSL_connect, 
SSL_accept or SSL_read.

I feel here we should not block the application call for long time, we should 
have some mechanism to fail the connection and inform application if we get 
invalid DTLS record continuously. For example, if we receive around 100 invalid 
DTLS record continuously, then we should come out of this "goto" in 
dtls1_get_record and return failure to application. And also we can send alert 
to peer and close the DTLS connection.

For similar issue in ssl3_get_record(), we are having a max 
limit(MAX_EMPTY_RECORDS) for the received empty record. I feel similar limit 
should be there for invalid DTLS record in dtls1_get_record.

Similarly in ssl3_get_message and dtls1_get_message_fragment, if we receive 
Hello request message continuously, then we are just dropping and continuously 
going back to read on socket. This also may cause a long time block to 
application, for the API SSL_connect if malicious peer is continuously sending 
Hello request msg.

I feel blocking of application call for a long time should be avoided. Please 
check this and clarify me, if my understanding is wrong.

Note : I am referring openssl-1.0.2k and asking this doubt.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
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

Re: [openssl-users] BN_MUL_MONT for ARM64 v8

[Andy Polyakov]

>   Is big number montogomery multiplication as optimized as it can be for
> ARM64 as compared to X86-64 from the latest openssl github ?
>   We are not seeing vmull ( or pmull/pmull2) instructions in
> armv8-mont.pl .  
>   
>On an ARM cortex-A72 (1GHz)  and E5-2620 (2.1 Ghz)  we are seeing an
> order of 10 difference in RSA signing perf for 2048 bit keys.

When it comes to performance correct question actually is not what is
the result in absolute terms, but how far is it from possible maximum
for specific processor [taking into consideration all the factors from
ISA capabilities and specific hardware implementation]. So that implying
that 10x difference between processors in question is result of
insufficient optimization for one is somewhat unjustified. Well, to be
completely honest there are some minor tricks one can pull on ARMv8, but
it will only make the gap a *little* bit smaller. Or in other words suck
it up, that's the way Cortex [currently?] is. If it's so critical *and*
you're in position to choose processor, then Samsung Mongoose core would
be much better choice (but I don't know anything about Qualcomm Kryo).
Yet, even though it would be better choice, it still wouldn't actually
close the gap, so don't get your hopes too high :-)

As for not seeing vector instructions. Pmull[2] is about something
completely different. As for vmull you have to recognize that it's
limited by 32-bit inputs and there is no carry handling in vector
instructions. This means that it would take more instructions to do same
job, even though you perform pair of multiplications in one vector
instruction. Well, it's more complicated than just amount of
instructions, but nevertheless, scalar 64x64 multiplication with carry
processing offered by ARMv8 ISA does deliver better result than 128-bit
vector instructions would.

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

Re: [openssl-users] Interoperating with a legacy client.

[Matt Caswell]

On 07/02/17 09:46, Tim Kirby wrote:
> On 2/6/2017 2:55 AM, Matt Caswell wrote:
>> This does look like the client is misbehaving for some reason. It's not
>> behaviour I can reproduce with a 1.0.1j version of s_client.
>>
>> The second ClientHello should have a TLS1.2 record version, not have the
>> SCSV ciphersuite, but instead have a renegotiation_info extension.
>>
>> Is the second ClientHello encrypted or in plaintext? If it is a
>> renegotiation then it would be encrypted. I am wondering whether for
>> some reason the client has forgotten its original connection, and is
>> attempting a second completely new TLS connection over the same
>> underlying TCP connection.
> 
> Good question!
> 
> I checked my traces again, and the second ClientHello is plaintext.
> 
> Starting a new TLS connection over the same TCP connection as an
> 
> existing, functional, TLS connection seems like a weird thing for the
> 
> client to do, but that would explain a second ClientHello that looks
> like an
> 
> initial connection.
> 
> 
> Assuming that's what's happening, is there a way I can detect it and start
> 
> a new connection instead?  Would it be safe to use a message callback to
> look
> 
> for a ClientHello, do an SSL_new() with the current context, and reuse
> the same BIOs?

By the time you hit the message callback OpenSSL will already have read
the ClientHello record from the BIO. Therefore by the time you created a
new SSL object and attempted the handshake the ClientHello would no
longer be available for reading.

Are you able to detect this at an application level? Is there something
about the application level protocol which might indicate that the
client is about to end the connection?

I assume there is no close_notify alert coming from the client
indicating the closure of the connection.

Ideally you would detect the closure in one of the above ways. If the
closure comes completely randomly and unpredictably then that's a bit
more difficult to deal with - although still possible.

I would probably write a custom BIO that inspects the incoming TLS
records looking for a handshake record with an unencrypted ClientHello
in it. If it detects one then it signals the closure to libssl - before
libssl has read the data out. You can then reuse the same BIOs and
context for a new SSL object.

Care should be taken though to make sure that, at an application level,
you treat this as a completely new connection - not a continuation of a
previous connection (which would have security implications).

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

[openssl-users] Why is the signing-time signed attribute added unconditionally in CMS signatures?

[Stephan Mühlstrasser]

Hi,

I'm wondering why OpenSSL adds the signing-time signed attribute 
unconditionally to a CMS signedData object. See function 
CMS_SignerInfo_sign() in source file cms_sd.c:


if (CMS_signed_get_attr_by_NID(si, NID_pkcs9_signingTime, -1) < 0) {
if (!cms_add1_signingTime(si, NULL))
goto err;
}

I found nothing in RFC 5652 that mandates the addition of the 
signing-time attribute. It's merely described as a "useful attribute".


The unconditional addition of the signing-time attribute is a problem 
when using OpenSSL for the creation of PAdES-conforming PDF signatures.


The ETSI standard ETSI TS 102 778-3 (PDF Advanced Electronic Signature 
Profiles; Part 3: PAdES Enhanced) explicitly requires the following:


http://www.etsi.org/deliver/etsi_ts/102700_102799/10277803/01.01.02_60/ts_10277803v010102p.pdf

"4.5.3 signing-time Attribute
For all profiles covered in the present document the signing-time 
attribute shall not be used."


So a CMS API flag would be useful that allows suppression of the 
signing-time attribute.


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

Re: [openssl-users] Interoperating with a legacy client.

[Tim Kirby]

On 2/6/2017 2:55 AM, Matt Caswell wrote:

This does look like the client is misbehaving for some reason. It's not
behaviour I can reproduce with a 1.0.1j version of s_client.

The second ClientHello should have a TLS1.2 record version, not have the
SCSV ciphersuite, but instead have a renegotiation_info extension.

Is the second ClientHello encrypted or in plaintext? If it is a
renegotiation then it would be encrypted. I am wondering whether for
some reason the client has forgotten its original connection, and is
attempting a second completely new TLS connection over the same
underlying TCP connection.


Good question!

I checked my traces again, and the second ClientHello is plaintext.

Starting a new TLS connection over the same TCP connection as an

existing, functional, TLS connection seems like a weird thing for the

client to do, but that would explain a second ClientHello that looks like an

initial connection.


Assuming that's what's happening, is there a way I can detect it and start

a new connection instead?  Would it be safe to use a message callback to 
look


for a ClientHello, do an SSL_new() with the current context, and reuse 
the same BIOs?



Thanks.


--

Tim Kirby

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