Re: [openssl-users] output from: dh, dhparam, pkeyparam
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
Re: [openssl-users] output from: dh, dhparam, pkeyparam
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
Re: [openssl-users] output from: dh, dhparam, pkeyparam
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
Re: [openssl-users] output from: dh, dhparam, pkeyparam
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
[openssl-users] output from: dh, dhparam, pkeyparam
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 smime.p7s Description: S/MIME Cryptographic Signature -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
