Hi Mat,
On 07/06/2016 12:38 PM, Mat Martineau wrote:

quoted

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.

The signature of verify_signature() is quite different from the other
new public key handlers, i.e. create_signature(), encrypt_blob(), and
decrypt_blob(). For verify_signature() we need the following parameters:
encrypted src, hash function to use, expected digest.
The expected digest could be optional if we would modify the
verify_signature() to return the decrypted buffer.
I think the best solution for now would be to just return -ENOPROTOOPT
for verify_signature in SET_KEY_ID mode.
All the four operations will be supported in the SET_KEY mode and
all but verify_signature() will be supported in the SET_KEY_ID mode.
This can added later if we will find a way to pass all parameters in a
consistent way. What do you think? If you are ok with that I will send a
new version soon.
Thanks,
-- 
TS