[openssl-users] DH custom param generation/usage

[Johann v. Preußen]

*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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160809/b06e586f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160809/b06e586f/attachment.bin>