On Mon, Sep 19, 2022 at 01:32:40AM +, 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.
