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
<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/
<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@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 <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
<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.
