verify¶
Operation¶
async
¶
verify(input: VerifyInput, plugins: list[Plugin] | None = None) -> VerifyOutput
Verifies a digital signature that was generated by the Sign operation.
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 SignatureValid field in the response is True. If the signature
verification fails, the Verify operation fails with an
KMSInvalidSignatureException exception.
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 Asymmetric KMS keys in the Key Management Service Developer Guide.
To use the Verify 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 Message
parameter should be hashed as part of the verification process.
You can also verify the digital signature by using the public key of the
KMS key outside of KMS. Use the GetPublicKey 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 Verify
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.
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 1234567812345678 as the distinguishing ID. For more information,
see Offline verification with SM2 key
pairs.
The KMS key that you use for this operation must be in a compatible key state. For details, see Key states of KMS keys in the Key Management Service Developer Guide.
Cross-account use: 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 KeyId parameter.
Required permissions: kms:Verify (key policy)
Related operations: Sign
Eventual consistency: The KMS API follows an eventual consistency model. For more information, see KMS eventual consistency.
Parameters:
| Name | Type | Description | Default |
|---|---|---|---|
input
|
VerifyInput
|
An instance of |
required |
plugins
|
list[Plugin] | None
|
A list of callables that modify the configuration dynamically. Changes made by these plugins only apply for the duration of the operation execution and will not affect any other operation invocations. |
None
|
Returns:
| Type | Description |
|---|---|
VerifyOutput
|
An instance of |
Input¶
dataclass
¶
Bases: _SerdeShape
Dataclass for VerifyInput structure.
Attributes¶
class-attribute
instance-attribute
¶
dry_run: bool | None = ...
Checks if your request will succeed. DryRun is an optional parameter.
To learn more about how to use this parameter, see Testing your permissions in the Key Management Service Developer Guide.
class-attribute
instance-attribute
¶
A list of grant tokens.
Use a grant token when your permission to call this operation comes from a new grant that has not yet achieved eventual consistency. For more information, see Grant token and Using a grant token in the Key Management Service Developer Guide.
class-attribute
instance-attribute
¶
key_id: str | None = ...
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.
To specify a KMS key, use its key ID, key ARN, alias name, or alias ARN.
When using an alias name, prefix it with "alias/". To specify a KMS
key in a different Amazon Web Services account, you must use the key ARN
or alias ARN.
For example:
-
Key ID:
1234abcd-12ab-34cd-56ef-1234567890ab -
Key ARN:
arn:aws:kms:us-east-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab -
Alias name:
alias/ExampleAlias -
Alias ARN:
arn:aws:kms:us-east-2:111122223333:alias/ExampleAlias
To get the key ID and key ARN for a KMS key, use ListKeys or DescribeKey. To get the alias name and alias ARN, use ListAliases.
class-attribute
instance-attribute
¶
message: bytes | None = ...
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 MessageType parameter with a value of DIGEST.
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.
class-attribute
instance-attribute
¶
message_type: str | None = ...
Tells KMS whether the value of the Message parameter should be hashed
as part of the signing algorithm. Use RAW for unhashed messages; use
DIGEST for message digests, which are already hashed; use
EXTERNAL_MU for 64-byte representative μ used in ML-DSA signing as
defined in NIST FIPS 204 Section 6.2.
When the value of MessageType is RAW, KMS uses the standard signing
algorithm, which begins with a hash function. When the value is
DIGEST, KMS skips the hashing step in the signing algorithm. When the
value is EXTERNAL_MU KMS skips the concatenated hashing of the public
key hash and the message done in the ML-DSA signing algorithm.
Warning
Use the DIGEST or EXTERNAL_MU value only when the value of the
Message parameter is a message digest. If you use the DIGEST value
with an unhashed message, the security of the signing operation can be
compromised.
When using ECC_NIST_EDWARDS25519 KMS keys:
-
ED25519_SHA_512 signing algorithm requires KMS
MessageType:RAW -
ED25519_PH_SHA_512 signing algorithm requires KMS
MessageType:DIGEST
Warning
When you specify the ED25519_PH_SHA_512 signing algorithm with
MessageType:DIGEST, KMS still performs the SHA-512 prehash described
in Step 1 of Section 7.8.1 in FIPS
186-5.
This means the input is hashed twice: once by you and once by KMS.
When the value of MessageType is DIGEST, the length of the Message
value must match the length of hashed messages for the specified signing
algorithm.
When the value of MessageType is EXTERNAL_MU the length of the
Message value must be 64 bytes.
You can submit a message digest and omit the MessageType or specify
RAW 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.
The hashing algorithm that Verify uses is based on the
SigningAlgorithm value.
-
Signing algorithms that end in SHA_256 use the SHA_256 hashing algorithm.
-
Signing algorithms that end in SHA_384 use the SHA_384 hashing algorithm.
-
Signing algorithms that end in SHA_512 use the SHA_512 hashing algorithm.
-
Signing algorithms that end in SHAKE_256 use the SHAKE_256 hashing algorithm.
-
SM2DSA uses the SM3 hashing algorithm. For details, see Offline verification with SM2 key pairs.
Output¶
dataclass
¶
Bases: _SerdeShape
Dataclass for VerifyOutput structure.
Attributes¶
class-attribute
instance-attribute
¶
key_id: str | None = ...
The Amazon Resource Name (key ARN) of the asymmetric KMS key that was used to verify the signature.
class-attribute
instance-attribute
¶
Metadata about the response that produced this output. Use this to recover the request identifiers a service's support team needs in order to investigate a call. Members of the metadata are individually optional.
class-attribute
instance-attribute
¶
signature_valid: bool = ...
A Boolean value that indicates whether the signature was verified. A
value of True indicates that the Signature was produced by signing
the Message with the specified KeyID and SigningAlgorithm. If the
signature is not verified, the Verify operation fails with a
KMSInvalidSignatureException exception.