GH-48334: [C++][Parquet] Support reading encrypted bloom filters

[fenfeng9]

Rationale for this change

Reading bloom filters from encrypted Parquet files previously raised an exception. This change implements encrypted bloom filter deserialization by decrypting the Thrift header (module id 8) and bitset (module id 9) separately, and adds the necessary validation and tests.

What changes are included in this PR?

• Wire metadata decryptor creation into the bloom filter reader
• Add BlockSplitBloomFilter::DeserializeEncrypted(...) for encrypted bloom filters
• Remove the fuzzer workaround that swallowed encrypted bloom filter exceptions

Are these changes tested?

Yes.

Are there any user-facing changes?

Yes.

• GitHub Issue: [C++][Parquet] Add support for encrypted Bloom filters #48334

[fenfeng9]

@pitrou Could you please take a look when you have a moment?

The C++ writer still rejects bloom filters when file encryption is enabled (ParquetException::NYI in file_writer.cc). Because of that, the tests here build an encrypted payload in memory to exercise the reader path.

arrow/cpp/src/parquet/file_writer.cc

Lines 484 to 489 in aea1ad3

	void WriteBloomFilter() {
	if (bloom_filter_builder_ != nullptr) {
	if (properties_->file_encryption_properties()) {
	ParquetException::NYI("Encryption is not currently supported with bloom filter");
	}
	// Serialize bloom filter after all row groups have been written and report

Do you think we should add writer-side support for encrypted bloom filters in this PR as well, or handle that in a follow-up?

[pitrou]

The C++ writer still rejects bloom filters when file encryption is enabled (ParquetException::NYI in file_writer.cc). Because of that, the tests here build an encrypted payload in memory to exercise the reader path.

How did you generate the encrypted payload? Ideally we should add a test file in https://github.com/apache/parquet-testing/tree/master/data (perhaps generated with another Parquet implementation?)

Do you think we should add writer-side support for encrypted bloom filters in this PR as well, or handle that in a follow-up?

It depends if you feel comfortable doing it!

[fenfeng9]

The C++ writer still rejects bloom filters when file encryption is enabled (ParquetException::NYI in file_writer.cc). Because of that, the tests here build an encrypted payload in memory to exercise the reader path.

How did you generate the encrypted payload? Ideally we should add a test file in https://github.com/apache/parquet-testing/tree/master/data (perhaps generated with another Parquet implementation?)

Thanks!
At the moment I didn’t run an end‑to‑end test. The test builds an encrypted payload in memory (serialize a BloomFilterHeader, encrypt header/bitset separately, then concatenate) to exercise the reader path without relying on the C++ writer.

I will update the tests with a real encrypted test file generated by another Parquet implementation and add it to parquet-testing.

[fenfeng9]

Marked as draft. Will add a real test file to parquet-testing and ping you when ready for review.

[pitrou]

Thanks for tackling this @fenfeng9 :)

[fenfeng9]

@pitrou Could you please review this when you have a moment? Thanks! There are some CI failures, but they seem unrelated to this PR

[fenfeng9]

@pitrou Friendly ping — this is ready for review. Thanks!

[wgtmac]

I just took a quick pass on this and it looks pretty good. Thanks for adding this!

[fenfeng9]

I just took a quick pass on this and it looks pretty good. Thanks for adding this!

Thanks for the review! I'll address these comments soon.

[wgtmac]

Thanks for your quick update! This looks good to me. I've left a minor comment w.r.t. error handling. Let me know what you think.

[wgtmac]

Thanks for bearing with me!

[wgtmac]

I've rebased this PR on top of the latest main branch to pass CIs and also updated parquet-testing to its latest commit. Will merge after CIs are complete. Thanks again @fenfeng9!

[wgtmac]

CI failures are unrelated, mostly due to failed with IOError: Bucket 'ursa-labs-r-test' not found. I'll merge it.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 3ecf1ca.

There was 1 benchmark result with an error:

• Commit Run on amd64-m5-4xlarge-linux at 2026-03-27 17:30:07Z
  • dataset-selectivity (Python) with dataset=nyctaxi_multi_parquet_s3, selectivity=100%

There were no benchmark performance regressions. 🎉

The full Conbench report has more details.