[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Verifying end-to-end data integrity\n\nThis page discusses using fields in the Cloud Key Management Service API to detect and prevent\nunintended changes to data as it moves between client systems and\nCloud KMS. These guidelines supplement the ways that Google Cloud\n[automatically protects your data](#automatic_data_protection) at rest and in\ntransit.\n\nAutomatic data protection\n-------------------------\n\nAll data on Google Cloud is automatically encrypted\n[in transit](/security/encryption-in-transit) and\n[at rest](/security/encryption/default-encryption) within\nGoogle Cloud.\n\nCloud KMS takes extra steps to protect encryption keys at rest\nby encrypting each encryption key using another cryptographic key called a\n*key encryption key* (KEK). To learn more about this technique, refer to\n[envelope encryption](/kms/docs/envelope-encryption).\n\nEach Cloud KMS cryptographic operation includes automatic checks\nfor data corruption. If corruption is detected, the operation is aborted and\na detailed error is logged.\n\nThese automatic protections are important, but they don't prevent client-side\ndata corruption. For example, data corruption during encryption can lead to data\nthat can't be decrypted.\n\nThis topic discusses ways to detect and prevent client-side data corruption to\nminimize the risk of data loss.\n| **Note:** It is strongly recommended that callers utilize the integrity verification scheme described below to minimize the risk of data loss caused by in-transit data corruption.\n\nCalculating and verifying checksums\n-----------------------------------\n\nEach cryptographic operation's request and response include\n[CRC32C checksum](http://tools.ietf.org/html/rfc4960#appendix-B)\nfields, such as `plaintext_crc32c`. You can calculate the checksum and compare\nthe calculated and returned values.\n\nOn the server, the Cloud Key Management Service API sets boolean fields, such as\n`verified_plaintext_crc32c`, to `true` to indicate that it received the relevant\nchecksum, and returns an `INVALID_ARGUMENT` error if the checksum doesn't match\nthe value calculated by the server.\n\nKeep the following guidelines in mind when calculating and comparing checksums:\n\n- Calculate checksums, using a binary encoding, as soon as data is sent or received.\n- Do not store unencrypted plaintext checksums to or from the Cloud Key Management Service API. For example, do not store the unencrypted contents of the `EncryptRequest.plaintext_crc32c` or `DecryptResponse.plaintext_crc32c` fields. To keep a record of a checksum, serialize it along with the relevant data and pass the compound object to Cloud KMS for encryption. When you decrypt data, you can verify the checksum against your calculated expected value.\n- If a decryption operation results in mismatched checksums, design your application to retry the operation a limited number of times, in case of transient problems.\n- If an encryption operation results in mismatched checksums for the encrypted data (the ciphertext), discard the encrypted result and try again.\n\nFor encryption requests:\n\n- If you include the checksum field in the request, the server sets a related\n verification field in the response to `true`\n to indicate that it received the checksum and attempted to verify its value.\n\n- If you include the checksum field but the response sets the verification field to\n `false`, the server did not receive the checksum field, and other information may\n be missing from the response. Retry the request a limited number of times in case\n the error is transient.\n\n- If the checksum was received but did not match, an `INVALID_ARGUMENT` error is\n returned. The error includes the name of the field and the checksum that didn't\n match. For example:\n\n ```\n The checksum in field plaintext_crc32c did not match the data in field plaintext.\n ```\n\n Retry the request a limited number of times in case the error is transient.\n\nFor decryption requests, you can calculate a checksum and compare it to the\nvalue of `DecryptResponse.plaintext_crc32c` in the response.\n\nThe following checksum fields are included in requests to and responses from the\nCloud Key Management Service API.\n\nVerifying resource names\n------------------------\n\nResponses for\n[Encrypt](/kms/docs/reference/rpc/google.cloud.kms.v1#google.cloud.kms.v1.EncryptResponse),\n[GetPublicKey](/kms/docs/reference/rpc/google.cloud.kms.v1#publickey),\n[AsymmetricSign](/kms/docs/reference/rpc/google.cloud.kms.v1#asymmetricsignresponse),\n[MacSign](/kms/docs/reference/rpc/google.cloud.kms.v1#macsignresponse),\nand\n[MacVerify](/kms/docs/reference/rpc/google.cloud.kms.v1#macverifyresponse),\ninclude a `name` field that contains the name of the relevant Cloud Key Management Service API\nobject. You can compare the value of the `name` field to the value you expect,\nand discard results that do not match.\n| **Note:** The `EncryptRequest.name` field can contain either a CryptoKey name or a CryptoKeyVersion name. However, the `EncryptResponse.name` field always contains a `CryptoKeyVersion` name. To convert a `CryptoKeyVersion` name to a CryptoKey name, strip `/cryptoKeyVersions/` and its value (such as `/cryptoKeyVersions/2`) from the field.\n\nData verification diagram\n-------------------------\n\nThis diagram shows when to verify each type of data related to cryptographic\noperations and when to verify data from each type of source. You can also view\na [summary of the data verification fields](#data_verification_field_summary).\n\nData verification field summary\n-------------------------------\n\nUse this tables when designing your application, to determine which fields you\ncan use to verify your data before and after each cryptographic operation.\n\n### Encrypt\n\n### Decrypt\n\n### AsymmetricSign\n\n### AsymmetricDecrypt\n\n### PublicKey\n\n### MacSign\n\n### MacVerify\n\nWhat's next\n-----------\n\n- Learn more about [symmetric](/kms/docs/encrypt-decrypt) and [asymmetric](/kms/docs/encrypt-decrypt-rsa) encryption\n- Learn more about [encrypting application data](/kms/docs/encrypting-application-data)\n- Use [Cloud Audit Logs](/kms/docs/audit-logging)"]]
