On Tue, 5 Jul 2016, Tadeusz Struk wrote:
Hi Mat,
On 06/29/2016 11:43 AM, Mat Martineau wrote:
+ ret = verify_signature(key, &sig);
+ if (!ret) {
+ req->dst_len = sizeof(digest);
I think you fixed the BUG_ON() problem but there's still an issue with
the handling of the digest. Check the use of sig->digest in
public_key_verify_signature(), it's an input not an output. Right now it
looks like 20 uninitialized bytes are compared with the computed digest
within verify_signature, and then the unintialized bytes are copied to
req->dst here.
With some modifications to public_key_verify_signature you could get the
digest you need, but I'm not sure if verification with a hardware key
(like a key in a TPM) can or can not provide the digest needed. Maybe
this is why the verify_signature hook in struct asymmetric_key_subtype
is optional.
+ scatterwalk_map_and_copy(digest, req->dst, 0, req->dst_len, 1);
+ }
So it looks like the only thing that we need to return to the user in
this case is the return code. Do you agree?
The way verify_signature is implemented today, the only output is the
return code. For verify, maybe no read is required (just sendmsg() and
check the return code).
But this isn't the extent of the problem: verify_signature needs both the
signature to be verified and the expected hash as inputs. How is the
expected hash provided? Would you include it as a cmsg header?
ALG_OP_VERIFY should have consistent inputs and outputs whether the key
was set with ALG_SET_KEY_ID or ALG_SET_KEY.
--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
