openssl-users Digest, Vol 94, Issue 24
A Z
poweruserm at live.com.au
Tue Sep 20 09:30:25 UTC 2022
Dear OpenSSL Users and Programmers,
I tried running the following command in Windows 64 bit Home edition,
and got the error:
>openssl req -nodes -newkey rsa:4096 -keyout pkey.pem -x509 -out cert.pem -days 36500 -subj -addext "subjectKeyIdentifier=hash"
req: Use -help for summary.
>openssl version
OpenSSL 3.0.0 7 sep 2021 (Library: OpenSSL 3.0.0 7 sep 2021)
In the email bundle reply, this line is suggested to generate a private key and a PEM certificate. How can I get this to run on
the Windows 10 64 bit, even when in Administrator mode?
Sergio Minervini.
________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of openssl-users-request at openssl.org <openssl-users-request at openssl.org>
Sent: Monday, 19 September 2022 10:00 PM
To: openssl-users at openssl.org <openssl-users at openssl.org>
Subject: openssl-users Digest, Vol 94, Issue 24
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: Best Practices for private key files handling (Michael Wojcik)
2. Problem with Asymetric, two-key encryption and Certificate
Requests. (A Z)
3. Re: Problem with Asymetric, two-key encryption and
Certificate Requests. (Viktor Dukhovni)
----------------------------------------------------------------------
Message: 1
Date: Sun, 18 Sep 2022 15:06:14 +0000
From: Michael Wojcik <Michael.Wojcik at microfocus.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: RE: Best Practices for private key files handling
Message-ID:
<DM6PR18MB270078332F7CA93F5EADD7EAF94A9 at DM6PR18MB2700.namprd18.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael
> Str?der via openssl-users
> Sent: Sunday, 18 September, 2022 04:27
>
> On 9/18/22 06:09, Philip Prindeville wrote:
> >> On Sep 15, 2022, at 4:27 PM, Michael Wojcik via openssl-users <openssl-
> users at openssl.org> wrote:
> >> You still haven't explained your threat model, or what mitigation
> >> the application can take if this requirement is violated, or why
> >> you think this is a "best practice".
>
> > The threat model is impersonation, where the legitimate key has been
> > replaced by someone else's key, and the ensuing communication is
> > neither authentic nor private.
>
> Maybe I'm ignorant but shouldn't this be prevented by ensuring the
> authenticity and correct identity mapping of the public key?
Exactly. In most protocols the public key, not the private key, authenticates the peer.
Relying on file system metadata (!) as the root of trust for authentication, particularly for an application that may be running with elevated privileges (!!), seems a marvelously poor design.
> > Otherwise, the owners of the system can't claim non-repudiation as to
> > the genuine provenance of communication.
I'm with Peter Gutmann on this. Non-repudiation is essentially meaningless for the vast majority of applications. But in any case, filesystem metadata is a poor foundation for it.
> More information is needed about how you're system is working to comment
> on this.
Indeed. This is far from clear here.
--
Michael Wojcik
------------------------------
Message: 2
Date: Mon, 19 Sep 2022 01:32:40 +0000
From: A Z <poweruserm at live.com.au>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Problem with Asymetric, two-key encryption and Certificate
Requests.
Message-ID:
<PU4P216MB1321AE67E6D7FBDA72BDFB859A4D9 at PU4P216MB1321.KORP216.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="iso-8859-1"
A#) openssl req -x509 -nodes -newkey rsa:4096 -keyout private.key -out public.key
B#) openssl smime -encrypt -binary -aes-256-cbc -in message.txt -out encrypted.dat -outform DER public.key
C#) openssl smime -decrypt -in encrypted.dat -binary -inform DEM -inkey private.key -out decrypted.txt
How can I complete step A#), so that step B#) will work, without involving a Certificate Request, which requires
a non-blank two digit nation code,
'You can set an empty issuer/subject DN, or use "-keyid" to avoid copying
these into the CMS message.'
Can someone please update my included A#), B#) or C#) instructions, included above here, to acheive
this suggestion, so that no certificate information is put into 'encrypted.dat', including the nation,
so that 'encrypted.dat' includes no plain text whatsoever, and so that A#) + B#) + C#) all work
as desired, for small, medium and large files, of 'message.txt'? I am struggling to correct what I
have done so far, so that there are no errors, and so that all the steps work: (generation of a private and public key,
encryption of the file, and decrypt of the file). ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220919/7e144f00/attachment-0001.htm>
------------------------------
Message: 3
Date: Sun, 18 Sep 2022 23:16:29 -0400
From: Viktor Dukhovni <openssl-users at dukhovni.org>
To: openssl-users at openssl.org
Subject: Re: Problem with Asymetric, two-key encryption and
Certificate Requests.
Message-ID: <YyffDSRHabZt1ISd at straasha.imrryr.org>
Content-Type: text/plain; charset=us-ascii
On Mon, Sep 19, 2022 at 01:32:40AM +0000, A Z wrote:
> A#) openssl req -x509 -nodes -newkey rsa:4096 -keyout private.key -out public.key
>
> B#) openssl smime -encrypt -binary -aes-256-cbc -in message.txt -out encrypted.dat -outform DER public.key
>
> C#) openssl smime -decrypt -in encrypted.dat -binary -inform DEM -inkey private.key -out decrypted.txt
>
> How can I complete step A#), so that step B#) will work, without
> involving a Certificate Request, which requires a non-blank two digit
> nation code,
>
> 'You can set an empty issuer/subject DN, or use "-keyid" to avoid
> copying these into the CMS message.'
>
> Can someone please update my included A#), B#) or C#) instructions,
> included above here, to acheive this suggestion, so that no
> certificate information is put into 'encrypted.dat', including the
> nation, so that 'encrypted.dat' includes no plain text whatsoever, and
> so that A#) + B#) + C#) all work as desired, for small, medium and
> large files, of 'message.txt'? I am struggling to correct what I have
> done so far, so that there are no errors, and so that all the steps
> work: (generation of a private and public key, encryption of the file,
> and decrypt of the file). ?
1. Generate the self-signed certificate using a configuration that
sets a subject key id.
2. Also set an empty subject name via "-subj /". The example also
sets a 100 year expiration time.
$ openssl req \
-nodes -newkey rsa:4096 -keyout pkey.pem \
-x509 -out cert.pem \
-days 36500 -subj / \
-addext "subjectKeyIdentifier=hash"
3. Use "openssl cms" insteadm of "openssl smime", and set the "-keyid"
option when encrypting.
$ openssl cms -keyid -encrypt -binary -aes-256-cbc \
-in /some/file -out /some/file.cms -outform DER \
-recip cert.pem
[ There appears to be a bug in the implementation of the
"-keyid" option in OpenSSL 1.1.1. It works with OpenSSL
3.0.5. ]
!!!! You're not *signing* the content. It is trivially spoofed, because
unless the public certificate is also kept secret, anyone can
encrypt a substitute file, and decryption will later succeed. !!!!
Instead of worrying about insignificant plaintext metadata, you
should be worrying about data integrity, and related actually
relevant issues, some noted below.
4. Again use "openssl cms" to decrypt.
$ openssl cms -decrypt -in /some/file.cms -binary -inform DER \
-inkey pkey.pem -out /some/file.dat
[ But see above, you have zero guarantee that the file has not
been tampered with by some with access to the non-secret public
key. ]
It is rather puzzling why it would be a problem to set some correct or
bogus 2-letter country code. It in no way compromises the security of
the data. That said, you can avoid this if it really bugs you.
As to the goal of encrypting "large files", note that neither CMS, nor
SMIME are particularly well suited in that regard. Decryption of CMS
messages brings the entire encrypted object into memory, this does not
scale well for "large files".
For large file encryption you'd ideally want to break the file into
chunks (say 4MB each), separately encrypt and MAC (HMAC is harder to
misuse than AEAD) each block's sequence number and data under a
symmetric key.
Then separately encrypt (and sign!) a data structure with any relevant
file metadata and symmetric key with CMS. (The metadata should
typically include the file name, modification time, ... so that
malicious substitution of some other file is later easier to detect).
A final < 4MB length block would signal the end of the file.
Decryption needs to verify the signature, decrypt the metadata, recover
the symmetric key, and then decrypt all or some of the blocks, verifying
the sequence numbers, and (if recovering the whole file) that the last
block (possibly empty) is shorter than the chunk size.
Decryption can then proceed one block at a time, with each block
verified independently without having to buffer the entire file.
A proper encrypted backup design requires more care than just naive use
of CMS (or its precursor S/MIME). You're fixating on entirely the wrong
set of issues.
--
Viktor.
------------------------------
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 94, Issue 24
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220920/9d938931/attachment-0001.htm>
More information about the openssl-users
mailing list