|
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@xxxxxxxxxxx> on behalf of openssl-users-request@xxxxxxxxxxx <openssl-users-request@xxxxxxxxxxx>
Sent: Monday, 19 September 2022 10:00 PM To: openssl-users@xxxxxxxxxxx <openssl-users@xxxxxxxxxxx> Subject: openssl-users Digest, Vol 94, Issue 24 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: 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@xxxxxxxxxxxxxx> To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx> Subject: RE: Best Practices for private key files handling Message-ID: <DM6PR18MB270078332F7CA93F5EADD7EAF94A9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="utf-8" > From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx> To: "openssl-users@xxxxxxxxxxx" <openssl-users@xxxxxxxxxxx> Subject: Problem with Asymetric, two-key encryption and Certificate Requests. Message-ID: <PU4P216MB1321AE67E6D7FBDA72BDFB859A4D9@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> To: openssl-users@xxxxxxxxxxx Subject: Re: Problem with Asymetric, two-key encryption and Certificate Requests. Message-ID: <YyffDSRHabZt1ISd@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx https://mta.openssl.org/mailman/listinfo/openssl-users ------------------------------ End of openssl-users Digest, Vol 94, Issue 24 ********************************************* |
