|
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@xxxxxxxxxxx> de la part de openssl-users-request@xxxxxxxxxxx <openssl-users-request@xxxxxxxxxxx>
Envoyé : mercredi 20 septembre 2023 10:42 À : openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> 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@xxxxxxxxxxx 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@xxxxxxxxxxx You can reach the person managing the list at openssl-users-owner@xxxxxxxxxxx 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@xxxxxxxxx> To: openssl-users@xxxxxxxxxxx Subject: Re: Openssl 1.1.1k specifications Message-ID: <ca51905c-630e-0c99-16e3-5aa25b306519@xxxxxxxxx> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 20.09.23 10:01, openssl-users-request@xxxxxxxxxxx digested: > Date: Wed, 20 Sep 2023 07:57:50 +0000 > From: Benjamin ENTE <benjamin.ente@xxxxxxxxxxxxx> > > 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@xxxxxxxxx> To: openssl-users@xxxxxxxxxxx Subject: Re: pkey public key extraction Message-ID: <6f7744af-857c-f731-e167-d9fcaeecba45@xxxxxxxxx> Content-Type: text/plain; charset="utf-8"; Format="flowed" On 20.09.23 10:01, openssl-users-request@xxxxxxxxxxx digested: > Date: Wed, 20 Sep 2023 07:28:46 +0000 > From: "Doody, Stephen" <s.doody@xxxxxxx> > > 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@xxxxxxxxxxx https://mta.openssl.org/mailman/listinfo/openssl-users ------------------------------ End of openssl-users Digest, Vol 106, Issue 18 ********************************************** |
