Openssl 1.1.1k specifications (Jochen Bern)

Wed Sep 20 09:04:31 UTC 2023

In that case you need to tell us more about how you are doing so. Are 
you using the openssl command line application or are you using a custom 
developed or third party application that uses OpenSSL's libcrypto?

If openssl command line are you using "openssl enc" or "openssl cms" to 
encrypt your files?

Matt

On 20/09/2023 10:01, Benjamin ENTE wrote:
> 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 
> <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/ 
> <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 <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 <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 
> <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.