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