output from: dh, dhparam, pkeyparam

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

output from: dh, dhparam, pkeyparam

Johann v. Preußen
since 0.9.6 or before, five (5) example PEM files have been included in the 'crypto/dh' directory of the pkg. these represent bit-sizes from 192 to 4096. certainly 192-/512-/1024-bits are hardly applicable today and that leaves the 2048-/4096-bit files subject to current interest. at that, i am not certain what utility these files have since they are not installed. quite a while ago i noticed the 'dh2048.pem' file when deciding to create custom DH param files. this file has two (2) sets of param's. since these files may have originated in some early dev phase, i can see where someone mistakenly appended the second param set instead of supplanting the first. this brings to the fore my actual question.

'pkeyparam' shares the same DH feature of its predecessors in that it ignores all content not included between the first PEM header and its accompanying footer. that means virtually anything can surround the first param and will be ignored by whatever call(s) this wrapper is making. i can understand that this may have been coded this way to allow for the history DH param's have with openssl whereby only the PKCS#3 variant has been supported and that format might co-exist in some files.

however, it would seem prudent that everything outside the first DH param should not be completely ignored. to wit: consider the very real possibility that a programmatic error is made -- such as the dh2048.pem example, supra -- and an append is performed and the new param is completely ignored and nobody is the wiser. moreover, since it is remarkably unlikely that anyone is hand coding these files or that comments would be inserted; it seems to make a lot of sense for a utilizing module to warn of excess content that is not PKCS and fail if more than a single PEM-type param is included.
-- 
Thank you,

Johann v. Preußen



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

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: output from: dh, dhparam, pkeyparam

Salz, Rich
OpenSSL behavior is pretty consistent, when reading a PEM file, everything before the first PEM marker (of the right type!) is ignored.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: output from: dh, dhparam, pkeyparam

Benjamin Kaduk
In reply to this post by Johann v. Preußen
What Rich said, and also note that it's perfectly valid usage of the PEM routines to read one type from a BIO and then go on to read another (potentially different) type from the same BIO, as would happen if they were in the same file concatenated after each other.  So, attempting to peek and see if there was other stuff after the read PEM object would be a strange special case.

-Ben

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: output from: dh, dhparam, pkeyparam

Jakob Bohm-7
On 08/08/2016 16:51, Benjamin Kaduk wrote:
> What Rich said, and also note that it's perfectly valid usage of the
> PEM routines to read one type from a BIO and then go on to read
> another (potentially different) type from the same BIO, as would
> happen if they were in the same file concatenated after each other.  
> So, attempting to peek and see if there was other stuff after the read
> PEM object would be a strange special case.
>
Maybe there should be a general
   check-no-more-data-in-file(BIO*,bool*bIsPEM)
routine called from the functions that take a file name as
argument, open it as a BIO, loads some PEM data and closes
the BIO, thus giving the caller no opportunity to use (or
check for) any extra PEM blocks (or DER blocks for DER
input).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: output from: dh, dhparam, pkeyparam

Benjamin Kaduk
On 08/10/2016 11:00 AM, Jakob Bohm wrote:
On 08/08/2016 16:51, Benjamin Kaduk wrote:
What Rich said, and also note that it's perfectly valid usage of the PEM routines to read one type from a BIO and then go on to read another (potentially different) type from the same BIO, as would happen if they were in the same file concatenated after each other.  So, attempting to peek and see if there was other stuff after the read PEM object would be a strange special case.

Maybe there should be a general
  check-no-more-data-in-file(BIO*,bool*bIsPEM)
routine called from the functions that take a file name as
argument, open it as a BIO, loads some PEM data and closes
the BIO, thus giving the caller no opportunity to use (or
check for) any extra PEM blocks (or DER blocks for DER
input).

That level of foot-shooting-protection seems overkill to me, though my opinion doesn't really matter since I'm not on the dev team.

-Ben

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