Re: PrivateKey Decrypt Failure

[Chitrang Srivastava]

Thanks very much, that worked.


On Wed, Sep 11, 2019 at 10:56 PM Wim Lewis  wrote:

>
>
> On Sep 11, 2019, at 3:31 AM, Chitrang Srivastava <
> chitrang.srivast...@gmail.com> wrote:
> > I am using openssl 1.1.1b and I am storing private key encrypted.
> >
> > I am storing private key as
> > PEM_write_bio_PrivateKey(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12,
> 0, 0, NULL);
>
> I don't think that PEM_write_bio_PrivateKey() will compute the key length
> for you if you pass 0. If you pass klen=0 it will encrypt with a 0-byte
> key. Try passing strlen(PKeyPassPKCS12) for klen and see if that helps.
>
>
>

Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Richard Levitte]

Thanks for the heads up.

For some reason, the information at our CDN remained incorrect for the
"BAD" files, so I purged all the current release files there, so their
cache for them would rebuild from scratch.  They look better now.

Cheers,
Richard

On Thu, 12 Sep 2019 00:25:40 +0200,
Carl Tietjen wrote:
> 
> 
> Still seeing the issue for SOME of the SHA256 files...  I waited for a while 
> thinking it might be
> a cache issue, but no change.
> 
> https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256  -- BAD
> 
> https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256  -- OK
> 
> https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD
> 
> https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK
> 
> https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 -- OK
> 
> -Original Message-
> From: Richard Levitte [mailto:levi...@openssl.org]
> Sent: Wednesday, September 11, 2019 2:41 PM
> To: Michael Wojcik 
> Cc: Carl Tietjen ; Matt Caswell 
> ;
> openssl-users@openssl.org
> Subject: Re: Problem with the SHA256 signatures (download files) for the new 
> releases 1.1.1d,
> 1.0.2t, 1.1.0l etc
> 
> Issue found...  Apache detected .gz in the file name and set the encoding to 
> 'application/
> x-gzip'...  Apparently, we already force .asc and .sha1 files to 
> application/binary, but have
> apparently not added a similar directive for .sha256 files.
> 
> Now done.
> 
> Cheers,
> 
> Richard
> 
> On Wed, 11 Sep 2019 22:04:53 +0200,
> 
> Michael Wojcik wrote:
> 
> >
> 
> > I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):
> 
> >
> 
> > -
> 
> > $ file openssl-1.1.1d.tar.gz.sha256
> 
> > openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT
> 
> > filesystem (MS-DOS,  OS/2, NT)
> 
> >
> 
> > $ file openssl-1.1.1d.tar.gz.sha1
> 
> > openssl-1.1.1d.tar.gz.sha1: ASCII text
> 
> >
> 
> > $ file openssl-1.1.1d.tar.gz.asc
> 
> > openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old)
> 
> >
> 
> > $ gpg --verify  openssl-1.1.1d.tar.gz.asc  openssl-1.1.1d.tar.gz
> 
> > gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491
> 
> > gpg: Good signature from "Matt Caswell " [full]
> 
> > gpg: aka "Matt Caswell " [full]
> 
> > -
> 
> >
> 
> > So the .sha1 file and the signature look fine, but the .sha256 file is 
> > apparently a fragment of
> gzip-compressed data. And ... let's see ... gunzip'ing it gives us the SHA256 
> hash in ASCII. So my
> guess the server is gzip'ing it (or it's gzip'ed at rest on the server), but 
> the server isn't
> setting the content-transfer-encoding correctly. Chrome might be 
> content-sniffing and
> decompressing based on that. I haven't looked at the response headers though.
> 
> >
> 
> > (Personally, I always check the signature and don't bother with the
> 
> > posted hashes.)
> 
> >
> 
> > --
> 
> > Michael Wojcik
> 
> > Distinguished Engineer, Micro Focus
> 
> >
> 
> >
> 
> --
> 
> Richard Levitte levi...@openssl.org
> 
> OpenSSL Project http://www.openssl.org/~levitte/
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

RE: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Carl Tietjen]

Still seeing the issue for SOME of the SHA256 files...  I waited for a while 
thinking it might be a cache issue, but no change.



https://www.openssl.org/source/openssl-1.0.2t.tar.gz.sha256  -- BAD

https://www.openssl.org/source/openssl-1.1.0l.tar.gz.sha256  -- OK

https://www.openssl.org/source/openssl-1.1.1d.tar.gz.sha256 -- BAD

https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz.sha256 -- OK

https://www.openssl.org/source/openssl-fips-ecp-2.0.16.tar.gz.sha256 -- OK





-Original Message-
From: Richard Levitte [mailto:levi...@openssl.org]
Sent: Wednesday, September 11, 2019 2:41 PM
To: Michael Wojcik 
Cc: Carl Tietjen ; Matt Caswell 
; openssl-users@openssl.org
Subject: Re: Problem with the SHA256 signatures (download files) for the new 
releases 1.1.1d, 1.0.2t, 1.1.0l etc



Issue found...  Apache detected .gz in the file name and set the encoding to 
'application/x-gzip'...  Apparently, we already force .asc and .sha1 files to 
application/binary, but have apparently not added a similar directive for 
.sha256 files.



Now done.



Cheers,

Richard



On Wed, 11 Sep 2019 22:04:53 +0200,

Michael Wojcik wrote:

>

> I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):

>

> -

> $ file openssl-1.1.1d.tar.gz.sha256

> openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT

> filesystem (MS-DOS,  OS/2, NT)

>

> $ file openssl-1.1.1d.tar.gz.sha1

> openssl-1.1.1d.tar.gz.sha1: ASCII text

>

> $ file openssl-1.1.1d.tar.gz.asc

> openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old)

>

> $ gpg --verify  openssl-1.1.1d.tar.gz.asc  openssl-1.1.1d.tar.gz

> gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491

> gpg: Good signature from "Matt Caswell 
> mailto:m...@openssl.org>>" [full]

> gpg: aka "Matt Caswell 
> mailto:fr...@baggins.org>>" [full]

> -

>

> So the .sha1 file and the signature look fine, but the .sha256 file is 
> apparently a fragment of gzip-compressed data. And ... let's see ... 
> gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is 
> gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't 
> setting the content-transfer-encoding correctly. Chrome might be 
> content-sniffing and decompressing based on that. I haven't looked at the 
> response headers though.

>

> (Personally, I always check the signature and don't bother with the

> posted hashes.)

>

> --

> Michael Wojcik

> Distinguished Engineer, Micro Focus

>

>

--

Richard Levitte levi...@openssl.org

OpenSSL Project http://www.openssl.org/~levitte/

Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Richard Levitte]

Issue found...  Apache detected .gz in the file name and set the
encoding to 'application/x-gzip'...  Apparently, we already force .asc
and .sha1 files to application/binary, but have apparently not added a
similar directive for .sha256 files.

Now done.

Cheers,
Richard

On Wed, 11 Sep 2019 22:04:53 +0200,
Michael Wojcik wrote:
> 
> I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):
> 
> -
> $ file openssl-1.1.1d.tar.gz.sha256
> openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem 
> (MS-DOS,
>  OS/2, NT)
> 
> $ file openssl-1.1.1d.tar.gz.sha1
> openssl-1.1.1d.tar.gz.sha1: ASCII text
> 
> $ file openssl-1.1.1d.tar.gz.asc
> openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old)
> 
> $ gpg --verify  openssl-1.1.1d.tar.gz.asc  openssl-1.1.1d.tar.gz
> gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491
> gpg: Good signature from "Matt Caswell " [full]
> gpg: aka "Matt Caswell " [full]
> -
> 
> So the .sha1 file and the signature look fine, but the .sha256 file is 
> apparently a fragment of gzip-compressed data. And ... let's see ... 
> gunzip'ing it gives us the SHA256 hash in ASCII. So my guess the server is 
> gzip'ing it (or it's gzip'ed at rest on the server), but the server isn't 
> setting the content-transfer-encoding correctly. Chrome might be 
> content-sniffing and decompressing based on that. I haven't looked at the 
> response headers though.
> 
> (Personally, I always check the signature and don't bother with the posted 
> hashes.)
> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/

Re: Support for /dev/*random in OpenSSL 1.1.1

[Dr Paul Dale]

As a temporary workaround, you might try defining __NR_getrandom to the 
appropriate system call number, although it looks like the extra efforts to get 
past the other preprocessor check ing rand_unit.c could get ugly.

What about defining your our getrandom function in your application that calls 
the system call?  The linker should find that before glibc’s.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 12 Sep 2019, at 1:48 am, Michael Brunnbauer  wrote:
> 
> 
> hi all,
> 
> I have glibc 2.30 with Kernel 4.9.191 but unfortunately I compiled glibc with
> old Kernel headers from Linux 3.16.46. It seems that as a result of this, my 
> getrandom() and getentropy() are stubs that always fail with ENOSYS. This 
> leads to:
> 
> ./util/shlib_wrap.sh apps/openssl rand -hex 10
> 4145686272:error:2406C06E:random number generator:RAND_DRBG_instantiate:error 
> retrieving entropy:crypto/rand/drbg_lib.c:342:
> ...
> 
> Fine I thought, supply --with-rand-seed=devrandom to Configure and be done
> with it until you can fix your glibc. Nope - same result.
> 
> Now I see this in e_os.h:
> 
> /*
> * Linux kernels 4.8 and later changes how their random device works and there
> * is no reliable way to tell that /dev/urandom has been seeded -- 
> getentropy(2)
> * should be used instead.
> */
> #   ifndef DEVRANDOM_SAFE_KERNEL
> #define DEVRANDOM_SAFE_KERNEL4, 8
> #   endif
> 
> So openSSL 1.1.1 will not support /dev/*random with Kernels > 4.8 ?
> 
> I can fix the kernel headers before compiling the next release of glibc but
> this is some months away.
> 
> Is there anything I can do now? I don't like the idea to recompile glibc - 
> Version upgrades are much easier to deploy than replacing the current version.
> 
> Regards,
> 
> Michael Brunnbauer
> 
> -- 
> ++  Michael Brunnbauer
> ++  netEstate GmbH
> ++  Geisenhausener Straße 11a
> ++  81379 München
> ++  Tel +49 89 32 19 77 80
> ++  Fax +49 89 32 19 77 89 
> ++  E-Mail bru...@netestate.de
> ++  https://www.netestate.de/
> ++
> ++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++  USt-IdNr. DE221033342
> ++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

RE: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Michael Wojcik]

I can confirm Carl's issue when I download using Pale Moon (a Firefox fork):

-
$ file openssl-1.1.1d.tar.gz.sha256
openssl-1.1.1d.tar.gz.sha256: gzip compressed data, from FAT filesystem (MS-DOS,
 OS/2, NT)

$ file openssl-1.1.1d.tar.gz.sha1
openssl-1.1.1d.tar.gz.sha1: ASCII text

$ file openssl-1.1.1d.tar.gz.asc
openssl-1.1.1d.tar.gz.asc: PGP signature Signature (old)

$ gpg --verify  openssl-1.1.1d.tar.gz.asc  openssl-1.1.1d.tar.gz
gpg: Signature made 09/10/19 09:13:14 EDT using RSA key ID 0E604491
gpg: Good signature from "Matt Caswell " [full]
gpg: aka "Matt Caswell " [full]
-

So the .sha1 file and the signature look fine, but the .sha256 file is 
apparently a fragment of gzip-compressed data. And ... let's see ... gunzip'ing 
it gives us the SHA256 hash in ASCII. So my guess the server is gzip'ing it (or 
it's gzip'ed at rest on the server), but the server isn't setting the 
content-transfer-encoding correctly. Chrome might be content-sniffing and 
decompressing based on that. I haven't looked at the response headers though.

(Personally, I always check the signature and don't bother with the posted 
hashes.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus

RE: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Carl Tietjen]

Weird.

-- When I switch to download with Chrome, the files are fine.

-- I retested using my default browser (Firefox) and I am still seeing the 
issue.

-- I tried it with IE and also see the issue.



Can you verify the Firefox and IE downloads.



Carl



-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Matt Caswell
Sent: Wednesday, September 11, 2019 11:10 AM
To: openssl-users@openssl.org
Subject: Re: Problem with the SHA256 signatures (download files) for the new 
releases 1.1.1d, 1.0.2t, 1.1.0l etc

On 11/09/2019 18:08, Carl Tietjen wrote:

> Hello,

>

> From the download site, https://www.openssl.org/source/ click the

> SHA256 link for the new releases.  The files do not contain SHA256 hashes.

>

> FYI -- The SHA1 hashes seem to be ok -- I only checked one.



These seem to be ok for me?



Matt

Re: Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Matt Caswell]

On 11/09/2019 18:08, Carl Tietjen wrote:
> Hello,
> 
> From the download site, https://www.openssl.org/source/ click the SHA256 link
> for the new releases.  The files do not contain SHA256 hashes.
> 
> FYI -- The SHA1 hashes seem to be ok -- I only checked one.

These seem to be ok for me?

Matt

Problem with the SHA256 signatures (download files) for the new releases 1.1.1d, 1.0.2t, 1.1.0l etc

[Carl Tietjen]

Hello,
>From the download site, https://www.openssl.org/source/ click the SHA256 link 
>for the new releases.  The files do not contain SHA256 hashes.
FYI -- The SHA1 hashes seem to be ok -- I only checked one.
Thanks,
Carl

Re: PrivateKey Decrypt Failure

[Wim Lewis]

On Sep 11, 2019, at 3:31 AM, Chitrang Srivastava 
 wrote:
> I am using openssl 1.1.1b and I am storing private key encrypted.
> 
> I am storing private key as
> PEM_write_bio_PrivateKey(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12, 0, 0, 
> NULL); 

I don't think that PEM_write_bio_PrivateKey() will compute the key length for 
you if you pass 0. If you pass klen=0 it will encrypt with a 0-byte key. Try 
passing strlen(PKeyPassPKCS12) for klen and see if that helps.

Support for /dev/*random in OpenSSL 1.1.1

[Michael Brunnbauer]

hi all,

I have glibc 2.30 with Kernel 4.9.191 but unfortunately I compiled glibc with
old Kernel headers from Linux 3.16.46. It seems that as a result of this, my 
getrandom() and getentropy() are stubs that always fail with ENOSYS. This 
leads to:

./util/shlib_wrap.sh apps/openssl rand -hex 10
4145686272:error:2406C06E:random number generator:RAND_DRBG_instantiate:error 
retrieving entropy:crypto/rand/drbg_lib.c:342:
...

Fine I thought, supply --with-rand-seed=devrandom to Configure and be done
with it until you can fix your glibc. Nope - same result.

Now I see this in e_os.h:

/*
 * Linux kernels 4.8 and later changes how their random device works and there
 * is no reliable way to tell that /dev/urandom has been seeded -- getentropy(2)
 * should be used instead.
 */
#   ifndef DEVRANDOM_SAFE_KERNEL
#define DEVRANDOM_SAFE_KERNEL4, 8
#   endif

So openSSL 1.1.1 will not support /dev/*random with Kernels > 4.8 ?

I can fix the kernel headers before compiling the next release of glibc but
this is some months away.

Is there anything I can do now? I don't like the idea to recompile glibc - 
Version upgrades are much easier to deploy than replacing the current version.

Regards,

Michael Brunnbauer

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail bru...@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel


signature.asc
Description: PGP signature

OpenSSL version 1.1.1d published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.1d released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.1d of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.1-notes.html

   OpenSSL 1.1.1d is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.1d.tar.gz
  Size: 8845861
  SHA1 checksum: 056057782325134b76d1931c48f2c7e6595d7ef4
  SHA256 checksum: 
1e3a91bc1f9dfce01af26026f856e064eab4c8ee0a8f457b5ae30b40b8b711f2

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.1d.tar.gz
openssl sha256 openssl-1.1.1d.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13oWoACgkQ2cTSbQ5g
RJFGjwf+IA34TBZZt/lwjtsALggJuoRrYyCBCDbdwJA+rBO2uQV2h+f7Tj5FBcuI
ARRhbUJqCDq7MFl1+6O5jPhTxZK0P1z242rOTvW50w4MFy+FZCwZjloxRBtgOlTy
y4t7yzuvCU1RidKiK9B42a6KypgQFEEHSlCkepNAjX94OLQhB+iF20vJ86gSFzrv
keJTUDXEbAa7I9MyK9p7SQbqHgFbTt0QAIYj/afNGOGv6ZyjiVrbp+4I29I0IG98
Dn4+4dp0xaY+oC1FTyO+lqfTLXuSnVR8TGDACHFyeQHCjf6wfSbFlxfH40CfeQzv
8vakK0+YhIAij7Pcm4te9ffUaSeNHg==
=jsdh
-END PGP SIGNATURE-

OpenSSL version 1.1.0l published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.1.0l released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0l of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.1.0-notes.html

   OpenSSL 1.1.0l is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.1.0l.tar.gz
  Size: 5294857
  SHA1 checksum: 6e3507b29e2630f56023887d1f7d7ba1f584819b
  SHA256 checksum: 
74a2f756c64fd7386a29184dc0344f4831192d61dc2481a93a4c5dd727f41148

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.1.0l.tar.gz
openssl sha256 openssl-1.1.0l.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13okkACgkQ2cTSbQ5g
RJFu5wf9HCvluEc1W1UwNqaw48n3g1ZclRdexYFO12HtUTTtriUwu0BPorvzHVmo
x4I0JzUxLeRXyS2kdBBPJC0OlPlrZMkWfwNy9IF2BRFGcMuGhjIOu60FfRNkGOM8
63RdIuSy1oPnwL4kUOdQi4pru1UcQVx25l4tpB6pLMKKgioGc1x75mP+C/lxhM16
PvPSo8pETU60V2QFaxzbfOqbS8LJhbO2m+dYCzgGy6Rjrd2CyzyZbtKC/bWoyMhW
s3jQ4oBjGh28y/mrzLup9oXP4f4/GlWajxd+pFXsj8xRfwEN7Zwg7eLlg6uZh6Cq
4KhsFKHIKgvba/lekhASdh71BdVVSA==
=na1Q
-END PGP SIGNATURE-

OpenSSL version 1.0.2t published

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


   OpenSSL version 1.0.2t released
   ===

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2t of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2t is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

 * https://www.openssl.org/source/
 * ftp://ftp.openssl.org/source/

   The distribution file name is:

o openssl-1.0.2t.tar.gz
  Size: 5355422
  SHA1 checksum: 8ac3fd379cf8c8ef570abb51ec52a88fd526f88a
  SHA256 checksum: 
14cb464efe7ac6b54799b34456bd69558a749a4931ecfd9cf9f71d7881cac7bc

   The checksums were calculated using the following commands:

openssl sha1 openssl-1.0.2t.tar.gz
openssl sha256 openssl-1.0.2t.tar.gz

   Yours,

   The OpenSSL Project Team.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13pssACgkQ2cTSbQ5g
RJFr9wf/X0fke/exS13hQb4h9RqE9fYouVbSNKTKhLp9X8BtYUOtUTjO5ispKt+1
BGWBotApoXBTopOsdJVXhzLtYst2YdKEtvyJAEFyxfpJa2PL4jmo5zxk93qWjDjA
u0HXR1Tu4XTLlE3EfqbfV/8bVO4kntTCk/xvg0gql1LUCVIRtjmqmsKOe7MJAHkH
94yb3kRFMpXb2YB6/zrK+ZuruL5ejTZCcXG7Dx9+LH5X7E/8KFDknk0Zo6w6970I
LbrXjtAOfHtVEK5XAFESCkMkjNqahopOs90AtemiOt1oOsNztjr7bVFHqJ3/oBMf
OYamiO1W2IhyxnPbet6zUDYG0FtYpw==
=sBvh
-END PGP SIGNATURE-

PrivateKey Decrypt Failure

[Chitrang Srivastava]

Hi,

I am using openssl 1.1.1b and I am storing private key encrypted.

I am storing private key as
*PEM_write_bio_PrivateKey*(bio, pkey, EVP_aes_128_cbc(), PKeyPassPKCS12, 0,
0, NULL);
and on system startup reading using the following way
 if(!*PEM_read_bio_PrivateKey*(keyBIO, _s_key, NULL,
decryptSharedSecret))

Upon debugging I found it is failing in PKCS12_pbe_crypt >
*EVP_CipherFinal_ex*
Please suggest where I am doing wrong?
Could this be appear to related to padding ?
Without encryption of key , it works fine , which clear other code is all
fine.

Thanks,

*evp_enc.c:EVP_DecryptFinal_ex:569*
/*
 * The following assumes that the ciphertext has been authenticated.
 * Otherwise it provides a padding oracle.
 */
n = ctx->final[b - 1];
if (n == 0 || n > (int)b) {

*EVPerr(EVP_F_EVP_DECRYPTFINAL_EX, EVP_R_BAD_DECRYPT);*
return 0;
}

OpenSSL Security Advisory

[OpenSSL]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

OpenSSL Security Advisory [10 September 2019]
=

ECDSA remote timing attack (CVE-2019-1547)
==

Severity: Low

Normally in OpenSSL EC groups always have a co-factor present and this is used
in side channel resistant code paths. However, in some cases, it is possible to
construct a group using explicit parameters (instead of using a named curve). In
those cases it is possible that such a group does not have the cofactor present.
This can occur even where all the parameters match a known named curve.

If such a curve is used then OpenSSL falls back to non-side channel resistant
code paths which may result in full key recovery during an ECDSA signature
operation.

In order to be vulnerable an attacker would have to have the ability to time
the creation of a large number of signatures where explicit parameters with no
co-factor present are in use by an application using libcrypto.

For the avoidance of doubt libssl is not vulnerable because explicit parameters
are never used.

OpenSSL versions 1.1.1, 1.1.0 and 1.0.2 are affected by this issue.

OpenSSL 1.1.1 users should upgrade to 1.1.1d
OpenSSL 1.1.0 users should upgrade to 1.1.0l
OpenSSL 1.0.2 users should upgrade to 1.0.2t

This issue was reported by Cesar Pereida García, Sohaib ul Hassan,
Nicola Tuveri, Iaroslav Gridin, Alejandro Cabrera Aldaya, and Billy Brumley. The
fix was developed by Billy Brumley. It was reported to OpenSSL on 5th August
2019.


Fork Protection (CVE-2019-1549)
===

Severity: Low

OpenSSL 1.1.1 introduced a rewritten random number generator (RNG). This was
intended to include protection in the event of a fork() system call in order to
ensure that the parent and child processes did not share the same RNG state.
However this protection was not being used in the default case.

A partial mitigation for this issue is that the output from a high precision
timer is mixed into the RNG state so the likelihood of a parent and child
process sharing state is significantly reduced.

If an application already calls OPENSSL_init_crypto() explicitly using
OPENSSL_INIT_ATFORK then this problem does not occur at all.

OpenSSL version 1.1.1 is affected by this issue.

OpenSSL 1.1.1 users should upgrade to 1.1.1d

This issue was reported by Matt Caswell. The fix was developed by Matthias
St. Pierre. It was reported to OpenSSL on 27th May 2019.


Padding Oracle in PKCS7_dataDecode and CMS_decrypt_set1_pkey (CVE-2019-1563)


Severity: Low

In situations where an attacker receives automated notification of the success
or failure of a decryption attempt an attacker, after sending a very large
number of messages to be decrypted, can recover a CMS/PKCS7 transported
encryption key or decrypt any RSA encrypted message that was encrypted with the
public RSA key, using a Bleichenbacher padding oracle attack. Applications are
not affected if they use a certificate together with the private RSA key to the
CMS_decrypt or PKCS7_decrypt functions to select the correct recipient info to
decrypt.

OpenSSL 1.1.1 users should upgrade to 1.1.1d
OpenSSL 1.1.0 users should upgrade to 1.1.0l
OpenSSL 1.0.2 users should upgrade to 1.0.2t

This issue was reported by and the fix developed by Bernd Edlinger. It was
reported to OpenSSL on 21st August 2019.


Note
=

OpenSSL 1.0.2 is currently only receiving security updates. Support for 1.0.2
will end on 31st December 2019.

Support for 1.1.0 ends on 11th September 2019 so 1.1.0l is expected to be the
last 1.1.0 release.

Users of these versions should upgrade to OpenSSL 1.1.1.


References
==

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20190910.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAl13vK0ACgkQ2cTSbQ5g
RJGJIgf+Me900bLV9TrVDWvNRQbuRe0tOPPhP59J4tJAJiRZ1GG0JV2YITQynjTP
hrz9mvajgWbkGYlTZmPVFOdJr7LKbrUrxk7shEfXqmiiCLG8tHYiCe3PF+/Cy7gA
X1vY9CDfv//3VSqOLM9RM3CCcWAAv3KeP851X0PgCiMVvGAJbYOu3bmB+KsEKFzm
fWRDabUMbl1KCSgCIvvlNv0bKR/GfpW3cWruUvG0sfjyPWwS+yn8z0T3/ibFJqkb
Cmuqa3/kC9uZg8AhiODR+nz6D1mC2UiNZ2Wa/XO6O68rO/y3ZKbaiMGLze1qJep5
3PnybOw8b3JvpVRFYw09YwgLObBX8w==
=8bP1
-END PGP SIGNATURE-

Re: Forthcoming OpenSSL Releases

[Matt Caswell]

On 03/09/2019 17:19, Matt Caswell wrote:
> The OpenSSL project team would like to announce the forthcoming release
> of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t.
> 
> These releases will be made available on 10th September 2019 between
> approximately 1200-1600 UTC.
> 
> These are security fix releases. The highest severity security issue fixed by
> these releases is rated as LOW.
> 
> Please note that this is expected to be the last release of 1.1.0 before it 
> goes
> out of support on 11th September 2019.

We have encountered some technical problems pushing these releases onto the
website today. Until those are resolved the release tarballs are not visible via
the standard links.

The releases are temporarily available at this non-standard location:

https://www.openssl.org/source/?

You can download them directly from there until such time as we fix the website.
We will send out the normal release announcements as soon as everything is
working normally again.

Regards

Matt




signature.asc
Description: OpenPGP digital signature