Google Cloud said on October 1, 2026 that end-to-end checksumming is now enabled by default in all Cloud Storage SDKs, so client libraries calculate a checksum for uploaded data and can verify checksums on download without extra work by developers.
What changed
In a post by distinguished software engineer Denis Serenyi and software engineer Yamini Allu, Google Cloud said the latest version of all Cloud Storage SDKs now internally checksums data being uploaded and passes that checksum to Cloud Storage if the application does not provide one. The SDKs also support verifying an object's checksum when it is downloaded.
According to Google, Cloud Storage has always allowed clients to supply a checksum on upload and receive one on download, and has stored a checksum for every object in its metadata since inception. But ensuring end-to-end integrity previously required extra developer work.
For partial reads, Google said that when its SDKs are used with the gRPC API to perform a range read, they use gRPC's built-in end-to-end range checksum to verify the data received.
The gap Google says it is closing
Cloud Storage always calculates the crc32 of data it receives and checks that data stored on disk matches, Google said. When an upload request does not include a checksum, however, the upload is vulnerable to a bit flip while data is in flight, before the server-side checksum is computed, and not all customers and clients enable client-side checksums by default.
Google said bit flips are not theoretical at its scale of hundreds of thousands of Cloud Storage frontends and happen from time to time.
Inside the chain of custody
Google described the internal steps it takes to keep data and checksums linked. After encrypting data in the frontend, it calculates a checksum over the ciphertext, decrypts the ciphertext again, and if the resulting plaintext does not match the original, it throws everything away and starts over. The company said this costs extra CPU time but is necessary.
Uploaded data is split into chunks, each with its own checksum, and thousands of chunks are grouped into gigabyte-sized shard files delivered to Colossus, Google's cluster-level storage system. Colossus uses Reed Solomon encodings to spread data across many disks and protect against failures of individual disks, machines and racks, chopping shard file data into blocks that are again checksum-protected.
Google said it exploits properties of cyclic redundancy checks, such as concatenation, so the CRC of two buffers can be computed cheaply from their individual CRCs. Data ultimately lands on disks managed by its "D" file server, which stores inline checksums for each range of data within a Colossus block; the Colossus client verifies reads against those inline checksums and the frontend verifies each chunk before sending it to the client.
What Google recommends
The company said it highly recommends updating to the latest SDK versions to take advantage of the integrity features, and repeated that recommendation at the end of the post.
What to do
- Update to the latest versions of the Cloud Storage SDKs, which Google says is needed to get the default end-to-end checksum protections.
- If your application already computes its own object checksums, you can keep passing them; Google says the SDK only adds a checksum when the application does not provide one.
- For partial downloads, use the Cloud Storage SDKs with the gRPC API so range reads are verified with gRPC's end-to-end range checksum.
Key facts and where they come from
- End-to-end checksumming is now on by default in all Cloud Storage SDKs.
enabling end-to-end checksumming by default in all the Cloud Storage SDKs
- SDKs compute an upload checksum when the application does not supply one.
the latest version of all Cloud Storage SDKs now internally checksums data being uploaded and passes this checksum to Cloud Storage, if it's not provided by the application
- Uploads without a client checksum were exposed to in-flight bit flips.
when an upload request doesn't include a checksum, that upload is vulnerable to a bit flip while the data is in-flight, prior to the server-side checksum computation
- Cloud Storage computes crc32 on received data and checks disk data against it.
Cloud Storage always calculates the crc32 (32-bit cyclic redundancy check) of data it receives and ensures data stored on disk matches this checksum
- Range reads over gRPC are verified using gRPC's built-in range checksum.
the SDKs take advantage of gRPC's built-in end-to-end range checksum, using it to verify the data it receives
- Google says bit flips occur at its scale of hundreds of thousands of frontends.
at our current scale of hundreds of thousands of Cloud Storage frontends, bit flips aren't theoretical and do happen from time to time
- Colossus uses Reed Solomon encodings across disks, machines and racks.
Colossus uses Reed Solomon encodings to spread data across many disks and protect against the failures of individual disks, machines, and racks