On 1/14/16, 13:56 , "Hubert Kario" <hkario at redhat.com> wrote: >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: >> If you already know what Dr. Henson explained in the quoted emails - >> then the man page is crystal clear. However, if you don't - then it >> is very easy (it was to me) to make an erroneous assumption (that is >> not explicitly contradicted) that the digest you specify would be >> applied to the data you are signing by pkeyutl itself. >> >> This is why I'm asking to include a statement (taking the relevant >> paragraph from Steve's email seems the best and the simplest way to >> me) somewhere in the beginning of the Notes section. That added >> statement/paragraph would make it unambiguously clear that specified >> or implied digest and it's parameters are used by pkeyutl ONLY for >> sanity checks and inclusion into the signature structure, but are NOT >> applied to the input data by pkeyutl (which instead the user must >> himself perform prior to invoking pkeyutl). >How about such change?: >--------->8---------- > >While the man page of pkeyutl mentions usage of hashes of data, >it is not explicit in that the data should be passed in >is the result of hashing and that the function will no perform >any hashing on the input data. I must admit that the above confuses me, even though now I *know* what it should mean. I would prefer something much simpler, like: Pkeyutl will not perform any hashing of the input data. The input data to be signed may or may not be a result of Hashing. Its size must be either equal to the digest output size if digest is specified or implied, or not greater than the size of the public key field or modulus otherwise. >This patch adds a note that makes this explicit. >--- > doc/apps/pkeyutl.pod | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod >index 27be9a9..b6f9e40 100644 >--- a/doc/apps/pkeyutl.pod >+++ b/doc/apps/pkeyutl.pod >@@ -135,6 +135,10 @@ and its implementation. The OpenSSL operations and >options are indicated below. > > Unless otherwise mentioned all algorithms support the B<digest:alg> >option > which specifies the digest in use for sign, verify and verifyrecover >operations. >+This value is used only for sanity-checking the lengths of passed in >data and +This value and that of the corresponding parameters if specified, is used +only for sanity-checking the lengths of passed in data and >+setting the values of signature structures (e.g. B<DigestInfo>) of the >+generated signature. In other words, if the value of digest is B<sha1> >the >+input should be 20 bytes long binary encoding of SHA-1 hash function. > The value B<alg> should represent a digest name as used in the > EVP_get_digestbyname() function for example B<sha1>. +If the digest is neither specified nor implied, the length of the +passed in data must be no greater than the public key modulus or +field size. > >-- >2.4.3 What do you think of the above? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160114/32d69b49/attachment.bin>
