Hi Mat, On 07/06/2016 12:38 PM, Mat Martineau wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
