Openssl 1.1.1k specifications (Jochen Bern)

Wed Sep 20 09:01:03 UTC 2023

Thank you for your answer Jochen Bern.

I'm sorry, my question was not detailed enough, we are using openssl to encrypt files.

Best regards

________________________________
De : openssl-users <openssl-users-bounces at openssl.org> de la part de openssl-users-request at openssl.org <openssl-users-request at openssl.org>
Envoyé : mercredi 20 septembre 2023 10:42
À : openssl-users at openssl.org <openssl-users at openssl.org>
Objet : openssl-users Digest, Vol 106, Issue 18

ATTENTION : Ce message vient de l'extérieur. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes si vous ne reconnaissez pas l'expéditeur ou si vous n'êtes pas sûr du contenu.

Send openssl-users mailing list submissions to
        openssl-users at openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        openssl-users-request at openssl.org

You can reach the person managing the list at
        openssl-users-owner at openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."

Today's Topics:

   1. Re: Openssl 1.1.1k specifications (Jochen Bern)
   2. Re: pkey public key extraction (Jochen Bern)

----------------------------------------------------------------------

Message: 1
Date: Wed, 20 Sep 2023 10:23:06 +0200
From: Jochen Bern <Jochen.Bern at binect.de>
To: openssl-users at openssl.org
Subject: Re: Openssl 1.1.1k specifications
Message-ID: <ca51905c-630e-0c99-16e3-5aa25b306519 at binect.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 20.09.23 10:01, openssl-users-request at openssl.org digested:
> Date: Wed, 20 Sep 2023 07:57:50 +0000
> From: Benjamin ENTE <benjamin.ente at cromology.com>
>
> I'm using OpenSSL 1.1.1k  FIPS .
>
> I'm asked for some audit if we are using rsa 2048 bits with padding PSS or Elliptic Curve (EDCSA) 256 bits.
>
> I don't know where to find this information and how to check it ?

The cryptosystem to use gets *negotiated* between client and server when
a TLS connection is initiated. Assuming that you're in control of the
server side and asked for a statement of how *that* behaves, the info
which ones the server is *willing* to agree to can be found in the
server app's setup, or be retrieved by outright *scanning* the server
(sslyze, https://www.ssllabs.com/ssltest/, whatever). OpenSSL and FIPS
may set boundaries on what the app *can* do, but they don't have the
last word on what it *does* do.

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230920/dd0371ab/attachment-0001.p7s>

------------------------------

Message: 2
Date: Wed, 20 Sep 2023 10:42:34 +0200
From: Jochen Bern <Jochen.Bern at binect.de>
To: openssl-users at openssl.org
Subject: Re: pkey public key extraction
Message-ID: <6f7744af-857c-f731-e167-d9fcaeecba45 at binect.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

On 20.09.23 10:01, openssl-users-request at openssl.org digested:
> Date: Wed, 20 Sep 2023 07:28:46 +0000
> From: "Doody, Stephen" <s.doody at cgi.com>
>
> We have a pem file that a colleague believes contains a private and a
> public key.

If it is PEM, it should have cleartext headers above every encoded block
*telling* you what data it contains, like so:

> # grep BEGIN [PT]*.pem *.crt *.key
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> PROD-CA.pem:-----BEGIN CERTIFICATE-----
> PROD-CA.pem:-----BEGIN X509 CRL-----
> TCP2443-dh2048.pem:-----BEGIN DH PARAMETERS-----
> TCP443-dh2048.pem:-----BEGIN DH PARAMETERS-----
> demux.crt:-----BEGIN CERTIFICATE-----
> demux.key:-----BEGIN RSA PRIVATE KEY-----

> The pubkey.pem file that is created only contains the public key and
> nothing else, so the 3rd party service can no longer connect to our
> system as it doesn't recognise this as a valid certificate and complained
> that it was not trusted.
[...]
> The 3rd party service can now connect to our system but viewing the
> details of the pubkey2.pem file it looks identical to the original
> ourcert.pem file.

If the 3rd party *really* needs a *certificate* to trust (an assertion
that that last paragraph casts considerable doubt on ...), then they'll
need to tell you which *CAs* they're willing to trust, and one of those
will need to create a new certificate for the keypair if your saved data
doesn't contain one. (Of course, their answer may be "set one up
yourself and we'll tell our software to trust *that* CA, too".) They
also should make mention of certain additional requirements (do they
connect to an IP, or a hostname? Does the cert need to confirm that
data? In the CN, the SANs, or both? etc.).

Without looking at the actual data, I'd agree that the pubkey2.pem file
likely contains *only* the public key, so your last paragraph suggests
that they *can* trust a *pubkey* instead ... in which case, mission
accomplished ... ?

Kind regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230920/13d3c877/attachment.p7s>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users

------------------------------

End of openssl-users Digest, Vol 106, Issue 18
**********************************************
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de ses destinataires et sont confidentiels. Si vous n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement l'expéditeur et de le détruire. Malgré nos mesures visant à nous prémunir des risques en termes de sécurité, nous vous recommandons de vous assurer de la non-introduction de virus dans votre système informatique. Tout message étant susceptible d'altération au cours de son acheminement, Cromology ne saurait être tenue pour responsable de dommage causé par la présence d'un virus dans ce message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230920/bb4a5f24/attachment.htm>