Re: Best Practices for private key files handling
> On Sep 15, 2022, at 4:27 PM, Michael Wojcik via openssl-users > wrote: > >> From: openssl-users On Behalf Of Philip >> Prindeville >> Sent: Thursday, 15 September, 2022 15:41 > >> I was thinking of the case where the directory containing the keys (as >> configured) is correctly owned, but contains a symlink pointing outside of >> that directory somewhere else... say to a file owned by an ordinary user. >> >> In that case, as has been pointed out, it might be sufficient to just pay >> attention to the owner/group/modes of the file and reject them if: >> >> (1) the file isn't 600 or 400; >> (2) the file isn't owned by root or the app-id that the app runs at. > > #2 is irrelevant if #1 holds and the application isn't running as root. And > if the application doesn't need to run with elevated privileges, it shouldn't > be run with elevated privileges. > > 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". > > It's true there's potentially some benefit to warning an administrator even > after the fact if some violation of key hygiene is detected, but whether > that's a "best practice" (and, for that matter, the extent to which file > permissions constitute evidence of such a violation), much less whether an > application should fail in some manner when it's detected, is certainly > debatable. > 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. The application should refuse to run if it's not finding a valid, sufficiently protected key. Otherwise, the owners of the system can't claim non-repudiation as to the genuine provenance of communication. -Philip
Re: Problem with Asymetric, two-key encryption and Certificate Requests.
On Thu, Sep 08, 2022 at 02:08:40AM +, A Z wrote:
> I have wanted to get into public/private two key encryption, of
> computer files of any type and any size and type. I am working on
> Windows 10 64 bit.I found the ensuing approach by my own
> experimenting, but it has a key disadvantage.
What threat model requires you to obscure all traces of cleartext
metadata in the encrypted message? In most common formats, in order to
facilitate algorithm agility, at least the encryption algorithm
identifier (often an ASN.1 OID) is included in the clear.
> In order for the encryption step to work by means of the public key,
> I have found the following approach with relies on the generation of a
> Certificate Request. The problem is however, that by doing things like this,
>
> A#) openssl req -x509 -nodes -newkey rsa:16384 -keyout private.key -out
> public.key
This actually generates a self-signed X.509 certificate. You can the
-subj / -days 3650
options to set empty subject and issuer DNs and (given self-signed cert)
a 10-year or longer validity. Use of RSA 16384 is ludicrous. Anything
longer than 4096 bits is just posturing and even that is overkill,
once/if 2048-bit RSA is broken, the rest will surely follow in quick
succession...
> B#) openssl smime -encrypt -binary -aes-256-cbc -in message.txt -out
> encrypted.dat -outform DER public.key
In S/MIME (or its more modern incarnation as CMS) each recipient's
wrapped key carries a suitable recipient identifier:
https://www.rfc-editor.org/rfc/rfc5652#section-6.2
KeyTransRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 0 or 2
rid RecipientIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
RecipientIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier [0] SubjectKeyIdentifier }
If you want to use a key identifier instead of (issuerDN + serial), you
can use the "-keyid" option of the cms(1) command, having first made
sure that the certificate you generate carries a subject key identifier.
> I can get plain text injected into the encrypted text, which I want to
> totally avoid every part of.
Your aversion to "plaintext" here looks poorly motivated. It is just
CMS (S/MIME) recipient metadata. CMS is not deniable encryption, the
outer layers of encapsulation are not encryption.
> 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.
--
Viktor.
Problem with Asymetric, two-key encryption and Certificate Requests.
Dear OpenSSL, I have wanted to get into public/private two key encryption, of computer files of any type and any size and type. I am working on Windows 10 64 bit.I found the ensuing approach by my own experimenting, but it has a key disadvantage. In order for the encryption step to work by means of the public key, I have found the following approach with relies on the generation of a Certificate Request. The problem is however, that by doing things like this, A#) openssl req -x509 -nodes -newkey rsa:16384 -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 I can get plain text injected into the encrypted text, which I want to totally avoid every part of. 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, which gets put into the encrypted text in plain manner, a situation which I want to do? How can I make A#) +B#) +C#) without certificate requests, without any nation code or plain text injection into the encrypted text at all, for small, medium, large, any size and type of file? Yours Sincerely, Sergio Minervini.
