*use case:* '/openssl genpkey -genparam -algorithm DH/'

the '/genpkey/' doc's '*DH PARAMETER GENERATION OPTIONS'* section:

 * first, before i forget -- again -- openssl's doc's should indicate that the
   using the '-pkeyopt' option requires that the 'dh_paramgen_generator'
   setting must precede the 'dh_paramgen_prime_len' if it is present or the
   setting is ignored and results in a default setting of '2' (which could
   stand to be mentioned as happening if the "generator" option is missing).
   Moreover, it also might be useful to mention the default for "len" is '1024'
   if the setting is missing.
 * this section could use a note that the '-text' option appends the
   PKCS#3-formatted data to the PEM-formatted data in the output. i am not
   knowledgeable enough re PKCS-bound app's to be aware of where this
   additional data might be required or if it is just a decade-old hold-over of
   no current value.
 * it also could be noted that '-outform' is ignored and the output default of
   'PEM' rules (while possibly being followed by the PKCS#3 data, as
   indicated). not everyone is aware that there is no such thing as a
   DER-formatted file for DH param's.

***DH param file controls:*
now, the '-out' option creates a parameter file or the output goes to stdout if missing. it is inconceivable that this option is not used in any automation mode and barely likely that it would be missing in a CLI environment because that would then require copying the stdout for insertion into some file. that leaves the possibility of errors in manual edits and the CLI/script mode wherein the stdout is '>' or '>>' to a file. obviously, '>>' or a language equivalent is an appending blooper worth preventing because the new param set will be ignored if a prior DH param set already exists in the file.

using the '-out' option is a not-so-strange 'special case' that openssl itself has created. while not stated in the doc's, using this option will silently over-write any pre-existent file and, thus, create a single-use file that can only be used for the provision of custom DH param's: no other param's, key, certs, or whatever that may have been present in the original file remain after running in this mode.

because this openssl-created result is a user/developer expectation (i.e., an openssl-established standard), it is reasonable to expect that openssl's down-stream modules will enforce this standard and that is not happening. later on, when the file is parsed, a search is made for the _*first*_ DH param set and everything else before and after (no matter whether it is other valid PEM data, a subsequent valid DH set, or just junk alpha-num lines) is completely ignored.

it is proposed that the openssl file-creation "standard" be enforced in all modules. such enforcement would serve to guard against human error that can creep into the file via manual edits and/or faulty scripting -- such as the ages-old openssl snafu in openssl's own packages in the 'crypto/dh/dh2048.pem' file which contains two (2) valid DH param sets and has been present in every package version since at least 0.9.6. while we are mentioning this example, it would prevent people from getting the wrong idea if the like-situated files representing bit-lengths of 192, 512, and 1024 were removed since virtually all current recommendations suggest starting at 2048 bits or more in 1024-bit steps.

the reason i have presented the need for further controls is because a real-world case was brought to me by one of my former students who was testing all the servers on his new job. he found that c. a third of the servers were running under very-old and far-less-secure param's than they thought were in use everywhere. we tracked it down to the same type of error that openssl itself made, supra.

if nobody thinks it is a good idea for openssl to prevent mistakes such as this happening and/or make clarifying additions to the doc's, there is no need to make further reply to this thread.

--
Johann


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Reply via email to