[openssl-users] [openssl-dev] pkeyutl does not invoke hash?

[Blumenthal, Uri - 0553 - MITLL]

Yes, and I can live with this update. 

I still think it would be nice to inform the user of ‎what to expect in the (unlikely but possible) case when his data is not an output of some cryptographic hash function. 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Hubert Kario
Sent: Friday, January 15, 2016 07:00
To: Blumenthal, Uri - 0553 - MITLL
Cc: openssl-dev at openssl.org; openssl-users at openssl.org
Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash?

On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote:
> 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.

The above was just a a comment to the patch, it needs to be
understandable only by the developers :), but yes, the wording
was quite clumsy. What was below it is what matters as that's what
ends up in the man page.


Second try:
------------->8-------------
>From a4f4971fc3bcc03c5aaead6844beded7f92ab01c Mon Sep 17 00:00:00 2001
From: Hubert Kario <hkario at redhat.com>
Date: Fri, 15 Jan 2016 12:58:22 +0100
Subject: [PATCH] clarify pkeyutl man page

Because pkeyutl does not perform hashing of any inputs but
the man page mentions data hashes, it's not obvious whether
the inputs to this function should be results of hashing or
the data itself.

This patch adds a note that makes this behaviour explicit.
---
doc/apps/pkeyutl.pod | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod
index 27be9a9..e885474 100644
--- a/doc/apps/pkeyutl.pod
+++ b/doc/apps/pkeyutl.pod
@@ -135,6 +135,13 @@ 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 data passed in to
+the B<pkeyutl> and for setting the values of the structures making up the
+signature (e.g. B<DigestInfo>). 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 output. In case the digest algorithm is not specified and is not
+implied by the key type and/or padding mode, the length of data must not be
+bigger than the key's modulus or field size (depending on key type).
The value B<alg> should represent a digest name as used in the
EVP_get_digestbyname() function for example B<sha1>.

-- 
2.4.3
------------->8-------------

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160115/546dc264/attachment-0001.sig>