verify ¶

def verify(
    self,
    key_id: "capo_kms.types.key_id_type.KeyIdType",
    message: "capo_kms.types.plaintext_type.PlaintextType",
    signature: "capo_kms.types.ciphertext_type.CiphertextType",
    signing_algorithm: "capo_kms.types.signing_algorithm_spec.SigningAlgorithmSpec",
    *,
    config_overrides: Optional[KMSClientConfig] = None,
    message_type: Optional["capo_kms.types.message_type.MessageType"] = None,
    grant_tokens: Optional["capo_kms.types.grant_token_list.GrantTokenList"] = None,
    dry_run: Optional[
        "capo_kms.types.nullable_boolean_type.NullableBooleanType"
    ] = None,
) -> "capo_kms.types.verify_response.VerifyResponse":
    """<p>Verifies a digital signature that was generated by the <a>Sign</a> operation. </p> <p></p> <p>Verification confirms that an authorized user signed the message with the specified KMS key and signing algorithm, and the message hasn't changed since it was signed. If the signature is verified, the value of the <code>SignatureValid</code> field in the response is <code>True</code>. If the signature verification fails, the <code>Verify</code> operation fails with an <code>KMSInvalidSignatureException</code> exception.</p> <p>A digital signature is generated by using the private key in an asymmetric KMS key. The signature is verified by using the public key in the same asymmetric KMS key. For information about asymmetric KMS keys, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/symmetric-asymmetric.html">Asymmetric KMS keys</a> in the <i>Key Management Service Developer Guide</i>.</p> <p>To use the <code>Verify</code> operation, specify the same asymmetric KMS key, message, and signing algorithm that were used to produce the signature. The message type does not need to be the same as the one used for signing, but it must indicate whether the value of the <code>Message</code> parameter should be hashed as part of the verification process.</p> <p>You can also verify the digital signature by using the public key of the KMS key outside of KMS. Use the <a>GetPublicKey</a> operation to download the public key in the asymmetric KMS key and then use the public key to verify the signature outside of KMS. The advantage of using the <code>Verify</code> operation is that it is performed within KMS. As a result, it's easy to call, the operation is performed within the FIPS boundary, it is logged in CloudTrail, and you can use key policy and IAM policy to determine who is authorized to use the KMS key to verify signatures.</p> <p>To verify a signature outside of KMS with an SM2 public key (China Regions only), you must specify the distinguishing ID. By default, KMS uses <code>1234567812345678</code> as the distinguishing ID. For more information, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/offline-operations.html#key-spec-sm-offline-verification">Offline verification with SM2 key pairs</a>.</p> <p>The KMS key that you use for this operation must be in a compatible key state. For details, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/key-state.html">Key states of KMS keys</a> in the <i>Key Management Service Developer Guide</i>.</p> <p> <b>Cross-account use</b>: Yes. To perform this operation with a KMS key in a different Amazon Web Services account, specify the key ARN or alias ARN in the value of the <code>KeyId</code> parameter. </p> <p> <b>Required permissions</b>: <a href="https://docs.aws.amazon.com/kms/latest/developerguide/kms-api-permissions-reference.html">kms:Verify</a> (key policy)</p> <p> <b>Related operations</b>: <a>Sign</a> </p> <p> <b>Eventual consistency</b>: The KMS API follows an eventual consistency model. For more information, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/accessing-kms.html#programming-eventual-consistency">KMS eventual consistency</a>.</p>

    Args:
        key_id: <p>Identifies the asymmetric KMS key that will be used to verify the signature. This must be the same KMS key that was used to generate the signature. If you specify a different KMS key, the signature verification fails.</p> <p>To specify a KMS key, use its key ID, key ARN, alias name, or alias ARN. When using an alias name, prefix it with <code>"alias/"</code>. To specify a KMS key in a different Amazon Web Services account, you must use the key ARN or alias ARN.</p> <p>For example:</p> <ul> <li> <p>Key ID: <code>1234abcd-12ab-34cd-56ef-1234567890ab</code> </p> </li> <li> <p>Key ARN: <code>arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab</code> </p> </li> <li> <p>Alias name: <code>alias/ExampleAlias</code> </p> </li> <li> <p>Alias ARN: <code>arn:aws:kms:us-east-2:111122223333:alias/ExampleAlias</code> </p> </li> </ul> <p>To get the key ID and key ARN for a KMS key, use <a>ListKeys</a> or <a>DescribeKey</a>. To get the alias name and alias ARN, use <a>ListAliases</a>.</p>
        message: <p>Specifies the message that was signed. You can submit a raw message of up to 4096 bytes, or a hash digest of the message. If you submit a digest, use the <code>MessageType</code> parameter with a value of <code>DIGEST</code>.</p> <p>If the message specified here is different from the message that was signed, the signature verification fails. A message and its hash digest are considered to be the same message.</p>
        message_type: <p>Tells KMS whether the value of the <code>Message</code> parameter should be hashed as part of the signing algorithm. Use <code>RAW</code> for unhashed messages; use <code>DIGEST</code> for message digests, which are already hashed; use <code>EXTERNAL_MU</code> for 64-byte representative μ used in ML-DSA signing as defined in NIST FIPS 204 Section 6.2.</p> <p>When the value of <code>MessageType</code> is <code>RAW</code>, KMS uses the standard signing algorithm, which begins with a hash function. When the value is <code>DIGEST</code>, KMS skips the hashing step in the signing algorithm. When the value is <code>EXTERNAL_MU</code> KMS skips the concatenated hashing of the public key hash and the message done in the ML-DSA signing algorithm.</p> <important> <p>Use the <code>DIGEST</code> or <code>EXTERNAL_MU</code> value only when the value of the <code>Message</code> parameter is a message digest. If you use the <code>DIGEST</code> value with an unhashed message, the security of the signing operation can be compromised.</p> </important> <p>When using ECC_NIST_EDWARDS25519 KMS keys:</p> <ul> <li> <p>ED25519_SHA_512 signing algorithm requires KMS <code>MessageType:RAW</code> </p> </li> <li> <p>ED25519_PH_SHA_512 signing algorithm requires KMS <code>MessageType:DIGEST</code> </p> </li> </ul> <important> <p>When you specify the ED25519_PH_SHA_512 signing algorithm with <code>MessageType:DIGEST</code>, KMS still performs the SHA-512 prehash described in <a href="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf#page=39">Step 1 of Section 7.8.1 in FIPS 186-5</a>. This means the input is hashed twice: once by you and once by KMS. </p> </important> <p>When the value of <code>MessageType</code> is <code>DIGEST</code>, the length of the <code>Message</code> value must match the length of hashed messages for the specified signing algorithm.</p> <p>When the value of <code>MessageType</code> is <code>EXTERNAL_MU</code> the length of the <code>Message</code> value must be 64 bytes.</p> <p>You can submit a message digest and omit the <code>MessageType</code> or specify <code>RAW</code> so the digest is hashed again while signing. However, if the signed message is hashed once while signing, but twice while verifying, verification fails, even when the message hasn't changed.</p> <p>The hashing algorithm that <code>Verify</code> uses is based on the <code>SigningAlgorithm</code> value.</p> <ul> <li> <p>Signing algorithms that end in SHA_256 use the SHA_256 hashing algorithm.</p> </li> <li> <p>Signing algorithms that end in SHA_384 use the SHA_384 hashing algorithm.</p> </li> <li> <p>Signing algorithms that end in SHA_512 use the SHA_512 hashing algorithm.</p> </li> <li> <p>Signing algorithms that end in SHAKE_256 use the SHAKE_256 hashing algorithm.</p> </li> <li> <p>SM2DSA uses the SM3 hashing algorithm. For details, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/offline-operations.html#key-spec-sm-offline-verification">Offline verification with SM2 key pairs</a>.</p> </li> </ul>
        signature: <p>The signature that the <code>Sign</code> operation generated.</p>
        signing_algorithm: <p>The signing algorithm that was used to sign the message. If you submit a different algorithm, the signature verification fails.</p>
        grant_tokens: <p>A list of grant tokens.</p> <p>Use a grant token when your permission to call this operation comes from a new grant that has not yet achieved <i>eventual consistency</i>. For more information, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#grant_token">Grant token</a> and <a href="https://docs.aws.amazon.com/kms/latest/developerguide/using-grant-token.html">Using a grant token</a> in the <i>Key Management Service Developer Guide</i>.</p>
        dry_run: <p>Checks if your request will succeed. <code>DryRun</code> is an optional parameter. </p> <p>To learn more about how to use this parameter, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/testing-permissions.html">Testing your permissions</a> in the <i>Key Management Service Developer Guide</i>.</p>

    Raises:
        capo_kms.errors.dependency_timeout_exception.DependencyTimeoutException: <p>The system timed out while trying to fulfill the request. You can retry the request.</p>
        capo_kms.errors.disabled_exception.DisabledException: <p>The request was rejected because the specified KMS key is not enabled.</p>
        capo_kms.errors.dry_run_operation_exception.DryRunOperationException: <p> The request was rejected because the DryRun parameter was specified. </p>
        capo_kms.errors.invalid_grant_token_exception.InvalidGrantTokenException: <p>The request was rejected because the specified grant token is not valid.</p>
        capo_kms.errors.invalid_key_usage_exception.InvalidKeyUsageException: <p>The request was rejected for one of the following reasons: </p> <ul> <li> <p>The <code>KeyUsage</code> value of the KMS key is incompatible with the API operation.</p> </li> <li> <p>The encryption algorithm or signing algorithm specified for the operation is incompatible with the type of key material in the KMS key <code>(KeySpec</code>).</p> </li> </ul> <p>For encrypting, decrypting, re-encrypting, and generating data keys, the <code>KeyUsage</code> must be <code>ENCRYPT_DECRYPT</code>. For signing and verifying messages, the <code>KeyUsage</code> must be <code>SIGN_VERIFY</code>. For generating and verifying message authentication codes (MACs), the <code>KeyUsage</code> must be <code>GENERATE_VERIFY_MAC</code>. For deriving key agreement secrets, the <code>KeyUsage</code> must be <code>KEY_AGREEMENT</code>. To find the <code>KeyUsage</code> of a KMS key, use the <a>DescribeKey</a> operation.</p> <p>To find the encryption or signing algorithms supported for a particular KMS key, use the <a>DescribeKey</a> operation.</p>
        capo_kms.errors.key_unavailable_exception.KeyUnavailableException: <p>The request was rejected because the specified KMS key was not available. You can retry the request.</p>
        capo_kms.errors.kms_internal_exception.KMSInternalException: <p>The request was rejected because an internal exception occurred. The request can be retried.</p>
        capo_kms.errors.kms_invalid_signature_exception.KMSInvalidSignatureException: <p>The request was rejected because the signature verification failed. Signature verification fails when it cannot confirm that signature was produced by signing the specified message with the specified KMS key and signing algorithm.</p>
        capo_kms.errors.kms_invalid_state_exception.KMSInvalidStateException: <p>The request was rejected because the state of the specified resource is not valid for this request.</p> <p>This exceptions means one of the following:</p> <ul> <li> <p>The key state of the KMS key is not compatible with the operation. </p> <p>To find the key state, use the <a>DescribeKey</a> operation. For more information about which key states are compatible with each KMS operation, see <a href="https://docs.aws.amazon.com/kms/latest/developerguide/key-state.html">Key states of KMS keys</a> in the <i> <i>Key Management Service Developer Guide</i> </i>.</p> </li> <li> <p>For cryptographic operations on KMS keys in custom key stores, this exception represents a general failure with many possible causes. To identify the cause, see the error message that accompanies the exception.</p> </li> </ul>
        capo_kms.errors.not_found_exception.NotFoundException: <p>The request was rejected because the specified entity or resource could not be found.</p>
        capo_kms.errors.UnknownServiceError: The service returned an error code this client does not model.

    Examples:
        To use an asymmetric KMS key to verify a digital signature
        This operation uses the public key in an elliptic curve (ECC) asymmetric key to verify a digital signature within AWS KMS.

        >>> client.verify(key_id='alias/ECC_signing_key', message='<message to be verified>', message_type='RAW', signature='<binary data>', signing_algorithm='ECDSA_SHA_384')
        To use an asymmetric KMS key to verify a digital signature on a message digest
        This operation uses the public key in an RSA asymmetric signing key pair to verify the digital signature of a message digest. Hashing a message into a digest before sending it to KMS lets you verify messages that exceed the 4096-byte message size limit. To indicate that the value of Message is a digest, use the MessageType parameter

        >>> client.verify(key_id='arn:aws:kms:us-east-2:111122223333:key/0987dcba-09fe-87dc-65ba-ab0987654321', message='<message digest to be verified>', message_type='DIGEST', signature='<binary data>', signing_algorithm='RSASSA_PSS_SHA_512')
    """

    def _handler(
        req: "OperationRequest[capo_kms.types.verify_request.VerifyRequest]",
    ) -> OperationResponse["capo_kms.types.verify_response.VerifyResponse"]:
        import capo_kms._operations.trent_service.verify

        output, http_response = capo_kms._operations.trent_service.verify.verify(
            req.options, req.input
        )
        return OperationResponse(output=output, response=http_response)

    def _redact_input(
        input_: "capo_kms.types.verify_request.VerifyRequest",
    ) -> dict[str, Any]:
        import capo_kms.types.verify_request

        return capo_kms.types.verify_request.redact_sensitive(input_)

    interceptors_, options_ = self.operation_options(
        config_overrides, OperationLogging("Verify", redact_input=_redact_input)
    )
    input_: capo_kms.types.verify_request.VerifyRequest = {
        "key_id": key_id,
        "message": message,
        "signature": signature,
        "signing_algorithm": signing_algorithm,
    }
    if message_type is not None:
        input_["message_type"] = message_type
    if grant_tokens is not None:
        input_["grant_tokens"] = grant_tokens
    if dry_run is not None:
        input_["dry_run"] = dry_run

    response = execute_pipeline(
        OperationRequest(input=input_, options=options_),
        handler=_handler,
        interceptors=list(interceptors_),
    )
    response.response.close()
    return response.output