Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Brian Morton via RT]

Thank you Steve (and Rich) for your insights so far.  It looks like BUF_MEM
is the structure in question?  If so, that might also explain the odd
behavior with smime encrypting which makes this issue sort of moot.  Even
if I could fix this, the encrypted files I've created so far would be
truncated I think.

I guess the safety check is to ensure that the structure works correctly
with other functions that put the result into an int type internally?

https://github.com/openssl/openssl/blob/3ce2fdabe6e33952bf3011acf5b68107e6352603/crypto/buffer/buffer.c#L19

Regardless of input size (2GB or 30GB) to the smime application, the
resulting encrypted file is only 1.9GB on disk.  Unless smime format has
some very serious compression, it looks like it is silently truncating
input.  A 32 bit integer dependency in the read buffer might explain that.
Is it related, or should I file that separately?

Brian

On Wed, Aug 17, 2016 at 6:54 PM, Stephen Henson via RT 
wrote:

> On Wed Aug 17 18:16:41 2016, bmor...@mortoninsights.com wrote:
> > That doesn't sound like an ideal case for a bugfix. Any other creative
> > ideas on how to fix this one? Some suggestions I read previously included
> > adding support for streaming decode to avoid such a large memory
> > allocation. This may not easily be feasible because of needing to verify
> > signatures on the message.
> >
>
> A streaming decode is one option but this is far from a trivial
> undertaking,
> Verifying signatures would be handled on the fly but you'll only know the
> signature is valid after all content has been processed of course.
>
> > If not, I'll try out the size_t change.
> >
>
> This is a significant job too. There is a major knock on effect with
> several
> APIs so it's not just a case of changing a few structures or we'd have
> done it
> already. It is planned for a future release though.
>
> As RIch mentioned one of the key structures has a dependency on int which
> is
> often 32 bits even on 64 bit systems.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Stephen Henson via RT]

On Wed Aug 17 18:16:41 2016, bmor...@mortoninsights.com wrote:
> That doesn't sound like an ideal case for a bugfix. Any other creative
> ideas on how to fix this one? Some suggestions I read previously included
> adding support for streaming decode to avoid such a large memory
> allocation. This may not easily be feasible because of needing to verify
> signatures on the message.
>

A streaming decode is one option but this is far from a trivial undertaking,
Verifying signatures would be handled on the fly but you'll only know the
signature is valid after all content has been processed of course.

> If not, I'll try out the size_t change.
>

This is a significant job too. There is a major knock on effect with several
APIs so it's not just a case of changing a few structures or we'd have done it
already. It is planned for a future release though.

As RIch mentioned one of the key structures has a dependency on int which is
often 32 bits even on 64 bit systems.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4650] BUG: parsing CRL with openssl

[Stephen Henson via RT]

It's a bug that is fixed in the current stable versions of OpenSSL and will be
in the next releases.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4650
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] Multithreading performance patches

[Andrey Kulikov]

Hi!

> The reason is that so far it was
> reserved for occasion like this, i.e. when somebody requests it and puts
> effort into testing it in real-life application:-) Can we do that?

I did it.
Added to crypto/cryptlib.c:

#  ifndef OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL
int OPENSSL_atomic_add(int *, int, int, const char *, int);
#  endif

and insert at the end of void OPENSSL_cpuid_setup(void)

#  ifndef OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL
CRYPTO_set_add_lock_callback(OPENSSL_atomic_add);
#  endif

So one could disable this feature by defining
OPENSSL_DISABLE_ATOMIC_ADD_INTERNAL macro at compile time.
Tested on Linux x86 and x64 during last 4 years on different high-load
SSL-servers.
Tested on Linux x86 and x64, Windows x86 and x64 in different SSL-client
applications.

No issues observed.

Cheers,
Andrey.

On 12 October 2012 at 18:19, Andy Polyakov  wrote:

> > I'm working on fast multithreaded TLS server for node.js, and I've
> > encountered few problems with openssl threading support which I would
> > like to address with attached patches.
> >
> > Please ask me if you have any questions or comments.
>
> As for 1st patch. Note that the section in question is guarded by 'if
> (add_lock_callback)'. add_lock_callback can be set by application and
> perform operation to its liking. In addition, on platforms with
> OPENSSL_CPUID_OBJ defined there is OPENSSL_atomic_add that can be used
> as callback, so that all you need to do then is
> CRYPTO_set_add_lock_callback(OPENSSL_atomic_add) in application code.
> Well, you'll surely get into trouble compiling this line, because
> OPENSSL_atomic_add is not declared. The reason is that so far it was
> reserved for occasion like this, i.e. when somebody requests it and puts
> effort into testing it in real-life application:-) Can we do that?
> Original idea behind OPENSSL_atomic_add was even to enable it
> automatically. On related note one can also add pointer manipulation
> subroutines so that one can maintain linked lists in lock-free manner...
>
> I'll have closer look at second patch and comment later on.
>
> __
> OpenSSL Project http://www.openssl.org
> Development Mailing List   openssl-dev@openssl.org
> Automated List Manager   majord...@openssl.org
>
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Kiyoshi KANAZAWA via RT]

Yes, __SUNPRO_C is defined by DeveloperStudio compiler.

> To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero

> isn't the right move here. So it seems that different compilers either only
> implement a subset of the __atomic builtins, or name them differently.
> 
> What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or
> something else? In that case, the correct method might be to exclude it, like
> this:
> 
> #if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)
> 
> On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
>>  Hello,
>> 
>>  % ./Configure solaris-x86-cc
>>  % make
>>  :
>>  Undefined first referenced
>>  symbol in file
>>  __atomic_add_fetch ./libcrypto.so
>>  ld: fatal: symbol referencing errors. No output written to
>>  fuzz/asn1parse-test
>> 
>> 
>>  % ./Configure solaris64-x86_64-cc
>>  % make
>>  has the same error.
>> 
>>  Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
>> 
>> 
>>  This is caused because __ATOMIC_RELAXED is #defined as 0
>>  in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
>> 
>> 
>>  Sample patch:
>>  --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
>>  +++ ./crypto/threads_pthread.c
>>  @@ -109,7 +109,7 @@
>> 
>>  int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK
>>  *lock)
>>  {
>>  -#ifdef __ATOMIC_RELAXED
>>  +#if __ATOMIC_RELAXED
>>  *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
>>  #else
>>  if (!CRYPTO_THREAD_write_lock(lock))
>> 
>> 
>>  With this patch,
>>  % ./Configure solaris-x86-cc
>>  % make
>>  % make test
>>  passes.
>> 
>>  % ./Configure solaris64-x86_64-cc
>>  % make
>>  passes but
>>  % make test
>>  stops.
>>  This is another problem, which seems to be the same as bug #4641.
>> 
>> 
>>  Regards,
>> 
>>  --- Kiyoshi 
> 
> 
> --
> Richard Levitte
> levi...@openssl.org
> 
> -- 
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
> Please log in as guest with password guest if prompted
>


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Brian Morton via RT]

That doesn't sound like an ideal case for a bugfix.  Any other creative
ideas on how to fix this one?  Some suggestions I read previously included
adding support for streaming decode to avoid such a large memory
allocation.  This may not easily be feasible because of needing to verify
signatures on the message.

If not, I'll try out the size_t change.

On Wed, Aug 17, 2016 at 2:02 PM, Salz, Rich via RT  wrote:

> Try it, it will be a huge invasive change.
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>
>


-- 
Brian Morton
Morton Software Insights
404-667-1095
bmor...@mortoninsights.com


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Salz, Rich via RT]

Try it, it will be a huge invasive change.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Salz, Rich]

Try it, it will be a huge invasive change.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Brian Morton via RT]

Hi Rich,

This is a 64 bit kernel on AMD64 architecture.  Do I need ints bigger than
that?  Any reason not to patch the code with size_t?  I could craft such a
change for a ticket if desired.

Thanks,

Brian

On Wed, Aug 17, 2016 at 1:28 PM, Rich Salz via RT  wrote:

> You'll need to move to a machine with bigger int's. The code currently uses
> int, not size_t.
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
> Please log in as guest with password guest if prompted
>
>


-- 
Brian Morton
Morton Software Insights
404-667-1095
bmor...@mortoninsights.com


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4651] [BUG] malloc_failure in ASN1_D2I_READ_BIO with large smime encoded file

[Brian Morton via RT]

Attempting to decrypt/decode a large smime encoded file created with
openssl fails regardless of the amount of OS memory available.

OpenSSL version 1.0.2d
Ubuntu 15.10 Linux 4.2.0-41 x86_64

Create keypair:

openssl req -x509 -nodes -newkey rsa:2048 \
-keyout mysqldump-secure.priv.pem \
-out mysqldump-secure.pub.pem

To create such a file on Linux:

dd if=/dev/urandom of=sample.txt bs=2G count=1

Encrypt/encode

openssl smime -encrypt -binary -text -aes256 -in sample.txt -out
sample.txt.enc -outform DER mysqldump-secure.pub.pem

Now decrypt/decode:

openssl smime -decrypt -binary -inkey mysqldump-secure.priv.pem -inform DEM
-in sample.txt.enc -out sample.txt.restored
*Error reading S/MIME message*
*14008102064:error:07069041:memory buffer
routines:BUF_MEM_grow_clean:malloc failure:buffer.c:159:*
*14008102064:error:0D06B041:asn1 encoding
routines:ASN1_D2I_READ_BIO:malloc failure:a_d2i_fp.c:255:*

Note that this problem occurs even on a system with 30GB+ of memory free.

Glad to take a stab at a patch if someone can point me in the right
direction as to the internal limitation.

Thank you,

Brian Morton

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4651
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4650] BUG: parsing CRL with openssl

[Mark Csaba via RT]

Hello,

 
I have a large CRL. It is 4503899 bytes long in DER format.

 
If I try to dump it with: openssl crl -inform DER -text -noout -in 
/tmp/user.crl I got an error:

unable to load CRL

139981611914920:error:0D09E09B:asn1 encoding routines:X509_NAME_EX_D2I:too 
long:x_name.c:203:

139981611914920:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=issuer, 
Type=X509_CRL_INFO

139981611914920:error:0D08303A:asn1 encoding 
routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error:tasn_dec.c:697:Field=crl, 
Type=X509_CRL

 
I tried this with:

-  OpenSSL 1.0.2h-fips

-  OpenSSL 1.0.1t

-  OpenSSL 1.0.1e-fips

Only OpenSSL 1.0.1e-fips ran without error and dumped the CRL.

Since one version ran smoothly I suppose the command is correct.

 
Is it really a bug in 1.0.2h or 1.0.2h needs different parameters?

 
Cheers

Csaba


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4650
Please log in as guest with password guest if prompted

<>-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Erik Forsberg]

as __atomic_* is non-standard, I propose guarding with __GNUC__
The C11 standard names are atomic_*
Would be nice if they could be supported ?

>-- Original Message --
>
>To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero
>isn't the right move here. So it seems that different compilers either only
>implement a subset of the __atomic builtins, or name them differently.
>
>What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or
>something else? In that case, the correct method might be to exclude it, like
>this:
>
>#if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)
>
>On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
>> Hello,
>>
>> % ./Configure solaris-x86-cc
>> % make
>> :
>> Undefined first referenced
>> symbol in file
>> __atomic_add_fetch ./libcrypto.so
>> ld: fatal: symbol referencing errors. No output written to
>> fuzz/asn1parse-test
>>
>>
>> % ./Configure solaris64-x86_64-cc
>> % make
>> has the same error.
>>
>> Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
>>
>>
>> This is caused because __ATOMIC_RELAXED is #defined as 0
>> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
>>
>>
>> Sample patch:
>> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
>> +++ ./crypto/threads_pthread.c
>> @@ -109,7 +109,7 @@
>>
>> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK
>> *lock)
>> {
>> -#ifdef __ATOMIC_RELAXED
>> +#if __ATOMIC_RELAXED
>> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
>> #else
>> if (!CRYPTO_THREAD_write_lock(lock))
>>
>>
>> With this patch,
>> % ./Configure solaris-x86-cc
>> % make
>> % make test
>> passes.
>>
>> % ./Configure solaris64-x86_64-cc
>> % make
>> passes but
>> % make test
>> stops.
>> This is another problem, which seems to be the same as bug #4641.
>>
>>
>> Regards,
>>
>> --- Kiyoshi 
>
>
>--
>Richard Levitte
>levi...@openssl.org
>
>-- 
>Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
>Please log in as guest with password guest if prompted
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

[Richard Levitte via RT]

On Fri Jul 08 09:36:42 2016, levitte wrote:
> On Fri Jul 08 09:33:01 2016, noloa...@gmail.com wrote:
> > Hmmm... If I want to use ld.gold as my linker, the easiest path is to
> > set LD=ld.gold. It makes perfect sense to some
>
> Did it work for you when doing this?
>
> ./config -fuse-ld=gold

Jeff, please respond.

--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4609
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4642] [openssl-1.1.0-pre6] make failes with solaris-x86-cc & solaris64-x86_64-cc

[Richard Levitte via RT]

To only allow the use of __atomic_add_fetch when __ATOMIC_RELAXED is non-zero
isn't the right move here. So it seems that different compilers either only
implement a subset of the __atomic builtins, or name them differently.

What was the macro defined by the DeveloperStudio compiler? __SUNPRO_C or
something else? In that case, the correct method might be to exclude it, like
this:

#if defined(__ATOMIC_RELAXED) && !defined(__SUNPRO_C)

On Mon Aug 08 08:33:34 2016, yoi_no_myou...@yahoo.co.jp wrote:
> Hello,
>
> % ./Configure solaris-x86-cc
> % make
> :
> Undefined first referenced
> symbol in file
> __atomic_add_fetch ./libcrypto.so
> ld: fatal: symbol referencing errors. No output written to
> fuzz/asn1parse-test
>
>
> % ./Configure solaris64-x86_64-cc
> % make
> has the same error.
>
> Tested on Solaris10 x86/64, with Solaris developerstudio12.5.
>
>
> This is caused because __ATOMIC_RELAXED is #defined as 0
> in /opt/developerstudio12.5/lib/compilers/include/CC/gnu/builtins.h
>
>
> Sample patch:
> --- ../openssl-1.1.0-pre6.orig/crypto/threads_pthread.c
> +++ ./crypto/threads_pthread.c
> @@ -109,7 +109,7 @@
>
> int CRYPTO_atomic_add(int *val, int amount, int *ret, CRYPTO_RWLOCK
> *lock)
> {
> -#ifdef __ATOMIC_RELAXED
> +#if __ATOMIC_RELAXED
> *ret = __atomic_add_fetch(val, amount, __ATOMIC_RELAXED);
> #else
> if (!CRYPTO_THREAD_write_lock(lock))
>
>
> With this patch,
> % ./Configure solaris-x86-cc
> % make
> % make test
> passes.
>
> % ./Configure solaris64-x86_64-cc
> % make
> passes but
> % make test
> stops.
> This is another problem, which seems to be the same as bug #4641.
>
>
> Regards,
>
> --- Kiyoshi 


--
Richard Levitte
levi...@openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4642
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4590] accessors without const return arguments

[Stephen Henson via RT]

On Wed Aug 03 21:13:08 2016, open...@roumenpetrov.info wrote:
>
> Please update documentation (status of 3.8.2016):
> 1) DSA_SIG_new.pod
> DSA_SIG_new() allocates and initializes a B structure.
>
> So now function only allocates signature.
>
>
> 2) ECDSA_SIG_new.pod
> ECDSA_SIG_new() allocates a new B structure (note: this
> function also allocates the BIGNUMs) and initializes it.
>
> Same here, but please indicate that this is changed in 1.1.
>

The documentation has now been fixed, thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4590
Please log in as guest with password guest if prompted

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

[openssl-dev] Error with async speed in OpenSSL 1.1.0-pre6

[Grandi, Andrea]

Hello!

We observed a failure when running speed with async jobs in the latest beta 
release.

> openssl speed -elapsed -async_jobs 1 dsa512
You have chosen to measure elapsed time instead of user CPU time.
Doing 512 bit sign dsa's for 10s: 70486 512 bit DSA signs in 10.00s
DSA verify failure.  No DSA verify will be done.
OpenSSL 1.1.0-pre6 (beta) 4 Aug 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib64/engines-1.1\""  -Wa,--noexecstack


I believe that this is caused by the following commit:
https://github.com/openssl/openssl/commit/0930e07d1eb522e663abe543ee865a508749946e

The changes were not necessary and the allocation of siglen in a separate 
buffer is actually required for the async jobs to work correctly.

After this commit the siglen is stored directly in tempargs.
When we start the ASYNC_JOB the struct is copied into the new execution context 
and all the changes done to siglen are visible only inside the ASYNC_JOB.

When the ASYNC_JOB finishes the async infrastructure does not copy the struct 
back in speed.
This is a design decision and not a bug in the async code.

In order to solve the error we need to pass siglen as a pointer so that the 
correct value is visible also from the caller (i.e. speed) and the verify 
operation can complete successfully.

Reverting the commit solves the problem:

git revert 0930e07d1eb522e663abe543ee865a508749946e


> openssl speed -elapsed -async_jobs 1 dsa512
You have chosen to measure elapsed time instead of user CPU time.
Doing 512 bit sign dsa's for 10s: 70485 512 bit DSA signs in 9.99s
Doing 512 bit verify dsa's for 10s: 119001 512 bit DSA verify in 10.00s
OpenSSL 1.1.0-pre6 (beta) 4 Aug 2016
built on: reproducible build, date unspecified
options:bn(64,64) rc4(16x,int) des(int) aes(partial) idea(int) blowfish(ptr)
compiler: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS 
-DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib64/engines-1.1\""  -Wa,--noexecstack
  signverifysign/s verify/s
dsa  512 bits 0.000142s 0.84s   7055.6  11900.1



Here is the link to the pull request: 
https://github.com/openssl/openssl/pull/1462

What do you think?


Kind regards,
Andrea

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4646] [1.0.2 stable branch] .\crypto\pem\pvkfmt.c(279): error C2065: 'PEM_R_HEADER_TOO_LONG': undeclared identifier

[Matt Caswell via RT]

This should be fixed now. Closing.

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4646
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4644] bug: cert verification always examining entire chain

[Matt Caswell via RT]

Closing this - "working as designed".

Matt

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4644
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] Partially- vs. full- reduced inputs to ecp_nistz256_neg

[Andy Polyakov]

>>> My understand after talking with Vlad that the "sbb \$0, $acc2" makes
>>> this equivalent to (r >= 2**256) ? (r - q) : r. If the "sbb \$0,
>>> $acc2" line were removed then it would be equivalent to (r >= q) ? (r
>>> - q) : r. My understanding is that the difference in semantics is
>>> exactly the difference between partially reduced results and fully
>>> reduced results.
>>
>> Let's recall that result of multiplication prior final reduction is
>> actually n+1-limb value, with +1 limb being single bit, that's $acc2,
>> 5th limb in the context. So that the $0 in last 'sbb \$0,$acc2'
>> represents 5th ("imaginary") limb of modulus[!]. And since we're looking
>> at borrow from this 5-limb subtraction, outcome is actually
>>
>> if (ret > P) ret -= P'
> 
> OK, let's agree on that.

Actually correct expression is 'if (ret >= P) ret -= P'.

> I think you are assuming that ret is in the range [0, 2P), so that if
> you subtract P, the result would be in the range [0, P). That is the
> case in normal Montgomery multiplication, where the inputs are in the
> range [0, P). But, my understanding is that if the inputs are in the
> range [P, 2**256), e.g. they are the result of ecp_nistz256_add, then
> that assumption doesn't necessarily hold.

Looks like you are right. I mean it indeed appears to be possible for
multiplication (and squaring) subroutine to return partially reduced
result. But *only* if input was partially reduced. I.e. if input is
fully reduced, the output *shall* be too. And if input is not fully
reduced, then output *can* be. And condition for "can" appears somewhat
tricky. If not fully reduced input was force-reduced and final condition
in 'if (ret >= P) ret -= P' was true, then output would be not fully
reduced.

> I understand Almost Montgomery Multiplication (AMM) as described in
> [1], where one accepts inputs in the range [0, 2**n] and returns a
> result in the range [0, 2**n), not [0, P).

And that one checks only the top bit. This means that partially reduced
output is possible even for fully reduced input.

> I also read the original paper on the ecp_nistz256 implementation [2],
> which has "0 ≤ a, b < p" as a precondition for the Montgomery
> multiplication.
> 
> To put my concern another way: Earlier in the thread, you said the
> function can take inputs that aren't fully reduced--i.e. are in in the
> range [0, 2**n)--and returns outputs that are fully reduced--i.e. in
> the range [0, P)

I was wrong, sorry about confusion.

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

Re: [openssl-dev] weird linker warnings on solaris 11

[Andy Polyakov]

>>> I went back to the 12.4 compiler which works very well, waste of my time
>>> to debug Oracle compiler, as we wont see any patches released anyway (no 
>>> support here)
>>
>> And I installed vendor compiler, 12.5, and I don't observe linker
>> warnings...
> 
>interesting, can I ask which Solaris version you were running ?
>I was running 11.3 (no SRU's), so still concerned this might
>come back when Solaris 12 ships

11.3 too. But probably more relevant question is what is your *linker*
version. Question is more or less rhetorical, because I'm not in
position to draw any conclusions based on particular version number. I
can only state that I myself get 5.11-1.2458 in reply to 'ld -V'. Though
it might be worth noting that cc calls /usr/ccs/bin/ld, while gcc -
/usr/bin/ld. But in my case these two are identical (though not hard- or
sym-linked).

>> On related note one should probably point out that x86[_64] compilation
>> with vendor compiler leaves out AVX and Broadwell code paths. This means
>> that you won't get adequate performance on latest hardware. But gcc
>> build should work with application compiled with vendor compiler, so why
>> not adhere to just that? I mean build OpenSSL with gcc and your
>> application with compiler of your choice, be it gcc or any particular
>> vendor compiler version.
>>
> 
>I may do that. I wasnt aware that AVX/Broadwell didnt build with cc 
> (64-bit)
>I was aware of lack of 32-bit asm support, so my 32-bit builds were using 
> gcc
>Thanks for looking.

To be completely accurate it boils down to *assembler* rather than
compiler. If gcc used vendor assembler, /usr/ccs/bin/as, then
AVX/Broadwell code would be left out too. But fortunately gcc available
from Oracle repository uses /usr/gnu/bin/as, and version I have is
2.23.1, which is sufficient for AVX1, AVX2 and Broadwell.

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

Re: [openssl-dev] Missing API- SSL_CIPHER_get_mac_nid

[Matt Caswell]

On 16/08/16 23:26, Richard Moore wrote:
> I noticed that we have:
> 
> __owur int SSL_CIPHER_get_bits(const SSL_CIPHER *c, int *alg_bits);
> __owur const char *SSL_CIPHER_get_version(const SSL_CIPHER *c);
> __owur const char *SSL_CIPHER_get_name(const SSL_CIPHER *c);
> __owur uint32_t SSL_CIPHER_get_id(const SSL_CIPHER *c);
> __owur int SSL_CIPHER_get_kx_nid(const SSL_CIPHER *c);
> __owur int SSL_CIPHER_get_auth_nid(const SSL_CIPHER *c);
> __owur int SSL_CIPHER_is_aead(const SSL_CIPHER *c);
> 
> which is great, but we seem to be missing an accessor to get the MAC.

If you fancy raising a github PR to add it then I will review it.

Matt

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