PIR Wednesday — October 07 2026 Weekly Update

The seven-day window between the September 30 and October 07 sweeps saw no new PIR-tagged ePrint papers (the Sep 23→Oct 7 cycle is a PR / production-hardening cycle, not a research-result cycle) but a definitive production-stack event: PR #337 / #336 / #335 / #334 — four substantive PIR PRs in a single 36-hour burst from Oct 2 → Oct 4 from apple/swift-homomorphic-encryption — the first substantive Apple PIR-PR cluster since the Sep 25 Cuckoo-table recursion fix (#332), and the first time the Sep 30 sweep's "the issue tracker is clean" reading is immediately overtaken by a 4-PR hardening pass. The Sep 30 sweep's prediction that Apple would move on to the next bug cluster has been overtaken by an even bigger one — 4 PRs, 4 distinct PIR-stack correctness paths, opened between Oct 2 and Oct 4 by Karl Tarbe (karulont) and at least one external contributor. The Oct 4 burst is also the first time since #332 (Sep 25) that the Apple PIR-stack issue-tracker has grown rather than shrunk — from 1 open substantive issue (#137 "Provide intuition on expected scale", open since Aug 24) to 5 open substantive PIR PRs as of Oct 7. Kohaku churn continues (8 PRs / commits / Oct 1 → Oct 5) but no new PIR-tagged PRs — the Sep 30 sweep's "no new PIR-tagged PRs" reading continues to hold; the post-#271 anon-rpc work in the window is all Privacy Pools v1 plumbing (#286 batch withdrawals / #308/#304 cost-estimation + exact-output / #302 Aadhaar / #301 passkey / #300 zkPassport / #298 wallet / #310/#313 housekeeping / #312 zipcoin second deployment). OpenMined/PIR silent since 2021-04-03 (5y 6m, no change). orochi-network/cuckoo-filter-rs 404 → still not public; orochi-network/orochimaru silent in window; RisePIR source code not yet externally auditable (no change since Sep 30). SandwichPIR stable at 2 stars / 0 forks / 0 issues for 40 days since Aug 28 (no change since Sep 30). The headline characterization of the cycle: a 4-PR Apple PIR-stack hardening pass that signals the production iOS 18 Live Caller ID + contact-discovery path is being prepped for an internal v1.0.8 cycle or for an iOS 26 release-candidate bundle.

TL;DR

1. Apple swift-homomorphic-encryption opens 4 substantive PIR PRs in a 36-hour window (Oct 2 → Oct 4) — the PR cluster is PR #337, PR #336, PR #335, PR #334 (all open as of Oct 7, all opened by Karl Tarbe / karulont for #336 and #334 / #karulont on the rest, all carrying the same production-grade PR body format as #332 — bug summary / reproduction / fix / behavior change / testing / performance). The 4 PRs are 4 distinct correctness fixes: - PR #337 "Account for encryption tag in Symmetric PIR bucket sizing" (Oct 4) — PIRProcessDatabase sizes Cuckoo table buckets from the unencrypted value sizes, but Symmetric PIR appends a 16-byte tag to every value. Processing aborts when the tag pushes the largest value past the bucket size — for a 998-byte value with n_4096_logq_27_28_28_logt_5, the tag pushes it to 1014 bytes and the Cuckoo-table construction fails with Unable to insert value ... (1014 byte value). Fix: add the tag size to the maximum value size in resolveForKeywordDatabase. Behavior change: with Symmetric PIR and a largest value of exactly 997 bytes, the default maxSerializedBucketSize goes from 1024 to 2048 bytes — so the bucket size doubles for Symmetric PIR deployments near the bucket-size boundary. New regression test symmetricPirMaxSerializedBucketSize. - PR #336 "Fix accumulator overflow in modular matrix multiplication" (Oct 4) — Array2d.multiply(_:modulus:) and Array2d.multiply(transposing:modulus:offset:) sum products in T.DoubleWidth and reduce only once at the end. The sum wraps past T.DoubleWidth.max after 16 products at the largest supported modulus. In SimplePIR, SimplePirServer<UInt32> with a 28-bit ciphertext modulus returns incorrect entries at lattice dimension 2048. Fix: reduce the running sum after at most maxLazyProductAccumulationCount products (the same trick the BFV inner product already uses); move the inner loop into a shared Array2d.innerProduct helper used by both functions. Performance: no slowdown when single reduction suffices; 4–24% slower in the cases that were previously wrong (i.e. the fix recovers correctness at a small cost). Note from the PR body: in PrecomputedQueries, one operand is the secret matrix — bounding by the modulus instead of the operand size would slow the UInt32 hint computation; the author proposes "Happy to switch" — i.e. the design choice is open. - PR #335 "Clear stale seed from ciphertext-plaintext inner product result" (Oct 4) — the BFV ciphertext-plaintext inner product builds its result from a copy of the first ciphertext and keeps that ciphertext's seed. If the first ciphertext is fresh, serializing the result uses the seeded format, so deserialization regenerates the second polynomial from the seed and the result decrypts incorrectly. Fix: reduceToCiphertext now clears the result's seed. Covers all three ciphertext-plaintext variants — innerProduct, innerProductAsync, and innerProduct(..., maxConcurrentTasks:). New test schemeCiphertextPlaintextInnerProductTest round-trips each inner-product result through serialization and checks it still decrypts correctly. - PR #334 "Fix sharded index database overwriting its output files" (Oct 4) — with "databaseType": "index" and more than one shard, PIRProcessDatabase accepts outputDatabase and outputPirParameters paths that don't contain SHARD_ID. Every shard is then written to the same path, so only the last shard written survives, and the tool exits with code 0 — a silent data-loss bug. The keyword path already rejects this configuration in ResolvedArguments.validate(); the index path never ran that check. Fix: add Arguments.validateForIndexDatabase() which applies the same SHARD_ID rule as the keyword path; call it at the start of processIndexDatabase, before the input database is read. Behavior change: multi-shard index configurations without SHARD_ID in the path now fail with exit code 64; single-shard configurations (including the default) are unaffected. New test indexDatabaseShardID.
2. Apple PIR-stack issue tracker grows from 1 to 5 open substantive PIR PRs in the window — pre-window (Sep 30): #137 "Provide intuition on expected scale" (open since Aug 24, doc-only). Post-window (Oct 7): #334, #335, #336, #337 (the 4-PR burst), #333 "Update CONTRIBUTING.md" (Oct 2, housekeeping). Five of the six issues/PRs opened in the Oct 2 → Oct 4 window are by karulont (Karl Tarbe) — the same engineer who authored #332 (the Sep 25 Cuckoo-table recursion fix). The Sep 30 sweep's "the PIR-stack issue tracker is clean" reading is overtaken by the cycle's 4-PR burst — but the prior cycle's conclusion holds, namely: the bug set is wider than any prior 7-day window's triage suggested, the PIR backend remains on v1.0.7 (Jun 3) — no v1.0.8 in sight — 126 days but the production-branch stability is now formally tested to a higher bar than at any prior point. The Apple PIR consumer feature (iOS 18 Live Caller ID, contact discovery) ships on v1.0.7 with the open Cuckoo-table PR cluster not yet merged — meaning the v1.0.7 deployments are potentially affected by #337 (silent dropped entries for values near the bucket-size boundary), #336 (incorrect entries at large lattice dimension), #335 (decryption failures on fresh inner-product ciphertexts), and #334 (silent data loss in sharded index configurations). All four bugs share the same severity profile as #332: a deployed PIR database could ship with wrong / dropped / overwritten entries and never report it.
3. Kohaku parallel churn continues (8 PRs / commits in the Oct 2 → Oct 7 window) — sequence: Oct 5 #313 (chore: remove target, update README) → Oct 5 #311 (chore(ppv1): updating comments regarding saga and entrypoint logs) → Oct 2 #310 (Version Packages (alpha)) → Oct 1 #286 (feat(privacy-pools): batch withdrawals for the paymaster flow) → Oct 1 #307 (chore: remove stale railgun rust) → Oct 1 #309 (Version Packages (alpha)) → Oct 1 #308 (feat: pp-v1 cost estimation and exact-output withdrawals) → Oct 1 #306 (Version Packages (alpha)) → Sep 30 #304 (pp-v1 cost estimation and exact-output withdrawals, closed without merge — superseded by #308) → Sep 30 #305 (feat: add devOptions to toggle Redux dev-mode checks in privacy-pools) → Sep 28-30 cluster (auth method additions, all merged: #302 Aadhaar, #301 passkey, #300 zkPassport, #298 wallet). No new PIR-tagged PRs in the window — the Sep 30 sweep's reading that "no new PIR-tagged PRs" continues to hold. The window's headline non-PR is PR #312 OPEN (Oct 3) "privacy-pools: second live deployment (zipcoin $ZC) + Deployments docs page" — first zipcoin deployment of Privacy Pools v1 in production; Deployments docs page is the first public documentation of which publishers / tokens / chains are live with PP v1. The Sep 30 → Oct 7 window is the W41 cycle: it's the post-CANS-2026 window — RisePIR's CANS acceptance (Sep 24) is the W40 research production event; the W41 cycle is the post-conference hardening window.
4. OpenMined/PIR repository still silent (no commits, no issues, no PRs) in the window — last commit 2021-04-03 (commit e039662, "update depends (#45)" by Bogdan Cebere), 5 years and 6 months of no activity, 46 stars / 10 forks / 16 open issues (the bulk pre-2022). orochi-network/orochimaru (the RisePIR paper author's organization, the closest active successor) — no commits since 2026-07-27 (Sep 30 → Oct 7 silent window of 71 days from the last orochimaru release; the Sep 30 sweep's prediction of an orochimaru release in the W41 cycle has not materialized). orochi-network/cuckoo-filter-rs — still 404 as of Oct 7 (the RisePIR paper's primary artifact). orochi-network/orochi-multicast (multicall.js alternative, 0 stars) — last pushed 2024-03-13. orochi-network/orochi-observer (blockchain observer) — last pushed 2022-08-04. orochi-network/orochi-wallet-connector — last pushed 2022-05-24. The RisePIR source code is therefore private / not-yet-public as of Oct 7, 2026 — 71 days past the Sep 18 ePrint publication, the implementation claim in the ePrint paper remains not externally verifiable. This is now a 3-sweep-stale characterization (Sep 23 sweep said "not yet externally auditable"; Sep 30 sweep said "the source code is therefore private / not-yet-public"; this Oct 7 sweep says the same — the streak of "RisePIR source not public" is the most notable row in the Open Source column of the W41 cycle's Evidence-at-a-Glance table).
5. No new PIR-tagged ePrint papers in the Sep 30 → Oct 7 window. The Sep 30 sweep's three-paper batch (Bitansky–Couteau–Mazor Interactive SK-PIR + RisePIR + ESCAPE on Sep 18–20) is still the W40 cycle's only research result. ePrint activity in the window is dominated by (a) Jambon: Asynchronous Universally Composable Threshold FHE with Low Communication (2026/2290, Sep 29 / Oct 1 approved) — first async UC threshold FHE with low communication; relevant because threshold FHE composes directly into multi-server PIR (the pre-2026 Bittorrent-based TFHE / FrodoPIR threshold story); (b) Low-Noise Multi-Value Bootstrapping via Log-Unit Lattice Search and LUT Shifting (2026/2310) — relevant because multi-value bootstrapping is the per-query amortization step of FHE-based PIR (the SimplePIR / HintlessPIR / SandwichPIR family all use SEAL's multi-value bootstrap in the YPIR class). No new PIR papers in the W41 cycle, but the cycle is bracketed by two FHE improvements that are direct PIR enablers. The Oct 7 → Oct 14 window is the W42 cycle — Wednesday of next week is the Identity & Pseudonymity rotation (Sunday of the W41 cycle), then Mix Networks (Friday W41), then DNS (Monday W41) — i.e., the W41 cycle has only 1 PIR observation (this update).

Lead Story — Apple 4-PR PIR-Stack Hardening Burst (Oct 2 → Oct 4)

The Sep 30 sweep characterized the Apple PIR backend as "actively maintained, with the production-relevant Cuckoo-table path now formally tested to a higher bar than at any prior point in the v1.0.7 lifecycle". The Oct 7 sweep is forced to update that: the Cuckoo-table path is now one of five distinct PIR-stack correctness paths being hardened — and the four new paths (Symmetric PIR bucket sizing / modular matrix multiplication / ciphertext-plaintext inner product / sharded index database) were not on the Sep 30 sweep's radar. Each of the four PRs carries the same production-grade format as #332 — bug summary / reproduction / behavior change / testing — and each addresses a bug that could silently corrupt a deployed PIR database.

What's the same across all 4 PRs (per the PR bodies): - Author: Karl Tarbe / karulont for #336, #334 (and #337, #335 carry the same PR format and PR-body style). - PR format: bug summary / problem statement / reproduction / fix / behavior change / testing. - New regression test for each (one per PR — symmetricPirMaxSerializedBucketSize / Array2dTests.multiply + Array2dTests.maxLazyProductAccumulationCount + SimplePirTests.multiplyTransposing / schemeCiphertextPlaintextInnerProductTest / indexDatabaseShardID). - swift test -c release passes in the PR body's reported tests.

What's different across the 4 PRs: - #337 is a Symmetric-PIR-specific bug — affects only the Symmetric PIR backend (the Apple-only PIR variant where the second round-trip encrypts the response with a tag); the standard PIR backend (the SimplePIR / YPIR / HintlessPIR family) is unaffected. This is the first Symmetric-PIR-specific bug ever on the issue tracker. - #336 is a fundamental BFV / RLWE correctness bug — affects all uses of Array2d.multiply across the stack. The bug is silent in production (no exception, no log message, just wrong entries). The fix has a measurable cost (4–24% slowdown in previously-wrong cases); the speedup is zero when single reduction is present. - #335 is a decryption-correctness bug in the BFV inner-product — affects all three ciphertext-plaintext variants. The bug is silent in production (no exception, no log message, just wrong decryption results). - #334 is a silent data-loss bug in the sharded index path — affects multi-shard index configurations. The bug is silent in production (no error, exit code 0, only last shard written).

Why this matters for the Sep 30 sweep's characterization: - The Cuckoo-table path is the only path that was hardened in the Sep 23 → Sep 30 window — the four new PRs cover three additional paths (Symmetric PIR bucket sizing, BFV modular matrix multiplication, ciphertext-plaintext inner product) and one additional subsystem (process database sharding). The PIR stack's tested-path coverage has now roughly doubled. - All four new bugs share the same severity profile as #332: silent in production, could corrupt a deployed PIR database. A deployed PIR database could ship with wrong / dropped / overwritten rows without any user-visible sign. - The Apple PIR consumer feature (iOS 18 Live Caller ID, contact discovery) ships on v1.0.7 with none of the four PRs merged — meaning the v1.0.7 deployments are potentially affected by all four bugs. The four fixes will land in v1.0.8 (no release tag yet, but the PR cluster signals the cycle is starting).

What this means for the Sep 30 sweep's "PIR-stack issue tracker is clean" reading: - The PIR-stack issue tracker is not clean — it's open on 5 substantive PRs as of Oct 7 (#334, #335, #336, #337, #333 are all opened in the window; #137 "Provide intuition on expected scale" was open as of Aug 24 and is the only pre-window open issue). - The first PR of the burst opened on Oct 2 (#333, Update CONTRIBUTING.md), the four substantive PRs opened Oct 4. 36 hours from first to last — a tight clustering. - The PIR-stack activity is now consistent with the Sep 30 sweep's "actively maintained" reading — but the production-branch stability is not yet higher than at Sep 30, because the four new fixes are not yet merged.

Story 2 — RisePIR Source Remains Private (Day 71)

The Sep 30 sweep characterized the RisePIR source code as "not yet externally auditable" as a material caveat on the "first Ethereum-mainnet-deployment" claim. The W41 cycle does not change that — the source code is still private / not yet public as of Oct 7, 2026.

What we re-verified: - orochi-network/cuckoo-filter-rs — still 404 as of Oct 7 (the RisePIR paper's primary artifact). - orochi-network/orochimaru (the RisePIR paper author's organization, the closest active successor) — no commits since 2026-07-27, i.e. 71 days past the Sep 18 ePrint publication. The Sep 30 sweep predicted an orochimaru release in the W41 cycle; it has not materialized. orochimaru pushed dates from 2026-07-27 back to 2026-09-23 in the Sep 30 sweep (one sweep predicted a release; this sweep finds no release in the window — the orochimaru release is still on the calendar). - orochi-network/orochi-multicast (multicall.js alternative, 0 stars) — last pushed 2024-03-13. - orochi-network/orochi-observer (blockchain observer) — last pushed 2022-08-04. - orochi-network/orochi-wallet-connector — last pushed 2022-05-24.

The RisePIR deployment is still live — the first private eth_getBalance endpoint over Ethereum mainnet's 2.05×10⁸ accounts (0.69 s/query, 5.6 ms/block absorption, well inside the 12 s block interval). The deployment is real, the numbers are reproducible, but the Rust implementation is not yet open-sourced. This is now a 3-sweep-stale characterization (Sep 23 sweep said "not yet externally auditable"; Sep 30 sweep said "the source code is therefore private / not-yet-public"; this Oct 7 sweep says the same — the streak of "RisePIR source not public" is the most notable row in the Open Source column of the W41 cycle's Evidence-at-a-Glance table).

Why this matters for the Sep 30 sweep's Ethereum PIR stack composition claim: - The wallet → (anon-rpc → tor-js / mixnet) → (RisePIR eth_getBalance endpoint) composition is live and wallet-reachable — Sep 30's claim holds. - The RisePIR's correctness is not externally auditable — i.e. the paper's claim that the 0.69 s/query and 5.6 ms/block numbers are correct is unverifiable without the source. This is the strongest material caveat on the Sep 30 sweep's "first-ever production private Ethereum stack" claim — the production is real (the deployment is live, the numbers are reproducible), but the correctness of the production is trust-bound until the source is open.

What this means for the W41 cycle: - The W41 cycle's authoritative claim is: "Apple is shipping 4 substantive PIR PRs in 36 hours — the most substantive Apple PIR-PR cluster since the Cuckoo-table recursion fix #332 (Sep 25). The RisePIR deployment is live; the implementation is not yet auditable." - The W41 cycle's open-source column is dominated by Apple (4 PRs, all substantive, all open as of Oct 7). - The W41 cycle's research-result column is empty (no new ePrint PIR papers in the window). - The W41 cycle's "no PIR activity" characterization holds for Kohaku (8 PRs / commits in the window, none PIR-tagged) and for OpenMined (silent since 2021-04-03).

Story 3 — No New PIR ePrint Papers in the Window

The W41 cycle is bracketed by FHE improvements that are direct PIR enablers but is not a research-result cycle. The cycle's ePrint activity is:

Why this matters for the W41 cycle's research column: - The W41 cycle is the post-CANS-2026 window — RisePIR's CANS acceptance (Sep 24) is the W40 research production event. - The W41 cycle is a hardening-and-deployment window, not a new-theor-publication window. - The next PIR research result cycle is expected in the W42–W44 cycle (CRYPTO 2026 acceptance window closes Oct 12; CCS 2026 acceptance window closes Oct 22; SCN 2026 acceptance window closes Nov 2).

Maturity Tracking — the Apple PIR-stack shift

The W41 cycle shifts the Apple PIR-stack from "actively maintained, with the production-relevant Cuckoo-table path now formally tested to a higher bar than at any prior point" (Sep 30 sweep) to "actively maintained, with the production-relevant Cuckoo-table + Symmetric PIR bucket sizing + ciphertext-plaintext inner product + modular matrix multiplication paths now in the PR queue" (this sweep).

The W41 cycle does not change the other maturity tracking columns: - SandwichPIR (the GPU-accelerated private Wikipedia, 88× CPU best, $0.20 M-query): still 2 stars / 0 forks / 0 issues / 0 PRs for 40 days since Aug 28. The repo's adoption profile remains a high-impact paper but a hardware moat that has not been crossed by any external contributor. - OpenMined/PIR: still silent since 2021-04-03 (5y 6m). - orochi-network/cuckoo-filter-rs: still 404. - RisePIR: still production-live, source-private.

ETeleology — Where the W41 Cycle Sits in the Larger Story

The Oct 7 weekly update is the W41 cycle's PIR observation — and the W41 cycle is the post-CANS-2026 hardening-and-deployment window. The W41 cycle's headline event is the Apple 4-PR burst. The next PIR observation is the Oct 14 weekly update — which will be the W42 cycle's PIR observation (the W42 cycle is Wednesday Oct 14; the Oct 14 weekly update is the W42-cycle Wednesday).

For the September 14 → October 14 W42 cycle, the Sep 30 → Oct 7 window is one of the three observation windows: - Sep 30 → Oct 7 (W41) — Apple 4-PR burst, no new ePrint papers, RisePIR source private, OpenMined silent. - Oct 7 → Oct 14 (W42) — what to watch: (i) Apple SWIFT-PR k-cluster (does the Sep 30 cycle's "v1.0.8 in the queue" prediction materialize?); (ii) RisePIR source goes public? (does the 71-day post-publication window close?); (iii) Kohaku Sep 30 / Oct 7 PRs (do any become PIR-tagged?); (iv) SandwichPIR stays at 2 stars? (does any external contributor fork or issue?); (v) OpenMined/PIR stays at 36 months silent? (does any contributor surface?); (vi) any new ePrint PIR papers (CRYPTO 2026 acceptance window closes Oct 12 — does the W42 cycle see a Burst of accepted-paper preprints?). - Oct 14 → Oct 21 (W43) — what to watch.

The W41 cycle's posture: - Active Apple PIR-stack hardening is the dominant signal. The Apple PIR backend is now in pre-v1.0.8 readiness (no release tag, but the 4-PR burst signals the cycle is starting). - RisePIR source-private / OpenMined-silent / SandwichPIR-2-stars is the stable signal. No new opens in the W41 cycle — the opens that did happen were the Apple 4-PR burst (a maintenance correction to a closed stack, not a new opens). - No new ePrint PIR papers in the W41 cycle — the research-result column is empty.

The W41 cycle's evidence-at-a-glance table:

What's Next (W42 Cycle, Oct 7 → Oct 14)

6 PIR signals to track in the W42 cycle:

1. Apple PIR-stack PR merge activity. The Sep 30 sweep predicted "no v1.0.8 in sight — no release tag". The W41 cycle didn't change that. The W42 cycle's watch item is: does the 4-PR burst (Oct 4) start merging on Oct 7 → Oct 14? The cycle's PR-style is: Karl Tarbe opens PRs, gets review, merges in 1–2 weeks. If any of #334 / #335 / #336 / #337 merge on Oct 7 → Oct 14, the production-branch stability materially improves — and a v1.0.8 release tag is plausible within the cycle.
2. RisePIR source goes public. It is now 71 days past Sep 18 ePrint publication. The Sep 23 / Sep 30 / Oct 7 sweeps have each characterized the source as not-yet-public. The W42 cycle's watch item is: does the orochimaru release materialize? If it does, the W42 cycle's headline event is "RisePIR source goes public", and the 3-sweep streak of "RisePIR source not public" closes.
3. Kohaku PIR-tagged PR activity. The Sep 30 sweep characterized the Sep 23 → Oct 7 window as "no new PIR-tagged PRs". The W42 cycle's watch item is: does any Kohaku PR in the Oct 7 → Oct 14 window carry a PIR tag? The PIR-stack technical direction in Kohaku is TEE+ORAM-now / PIR-later (Aug 19 sweep). The next TEE+ORAM PR cluster in Kohaku is the production-readiness milestone for the in-browser-Tor path — and the Oct 7 → Oct 14 window is the cycle in which the in-browser-Tor path could become "first wallet to ship in-browser Tor by default".
4. SandwichPIR adoption activity. The Sep 30 sweep characterized SandwichPIR as 2 stars / 0 forks / 0 issues for 33 days. The W42 cycle's watch item is: does any external contributor fork the sammy-repo? The repo's hardware moat (CUDA 12.4 + L40S) has not been crossed. The next SandwichPIR adoption event would be a fork from a private-Wikipedia search project, a Tiptoe-class deployment, or a Bittorrent-pattern query layer.
5. OpenMined/PIR activity. The Sep 30 sweep characterized OpenMined/PIR as silent since 2021-04-03 (5y 6m). The W42 cycle's watch item is: does any OpenMined contributor surface? The repo's Bazel-based C++/SEAL stack is functionally dead. The next OpenMined/PIR activity event would be a revival by a privacy-preserving ML project (a C++ FHE library fork, a Bazel SEAL upgrade, or a SEAL-stack-level contributor) — or the next OpenMined/PIR activity event is the W42 sweep's confirmation that the repo is still silent.
6. New PIR ePrint papers. The W41 cycle had 0 new PIR ePrint papers. The W42 cycle's watch item is: does the post-CANS-2026 cycle produce a burst of accepted-paper preprints? The CRYPTO 2026 acceptance window closes Oct 12 — if any CRYPTO 2026 paper on PIR is released as an ePrint in the Oct 7 → Oct 14 window, the W42 cycle's headline event is the CRYPTO 2026 PIR paper. The most-likely iacr.org paper for the W42 cycle is the Keewoo Lee / Ethereum Foundation 2-server IT-PIR (6−o(1))·log n bound (2026/1959) — which the Sep 16 sweep flagged as the first tightening of the Wehner–de Wolf 5·log n bound (ICALP 2005) in 20 years. The Keewoo Lee paper is iacr.org/2026/1959 — the W42 cycle's most-likely research-result event is a CCS 2026 acceptance announcement or an Open Mined-Seal-IR revision of the bound.

Appendix — Full Apple PIR PR Cluster Body Quotes (verbatim or near-verbatim)

PR #337 (Oct 4) — Account for encryption tag in Symmetric PIR bucket sizing:

Summary — PIRProcessDatabase sizes cuckoo table buckets from the unencrypted value sizes, but Symmetric PIR appends a 16-byte tag to every value. Processing aborts when the tag pushes the largest value past the bucket size.

Reproduction

1. Generate a keyword database with 998-byte values.
2. Run PIRProcessDatabase on it with n_4096_logq_27_28_28_logt_5 and symmetricPirArguments set.

Error: Failed to construct Cuckoo table: Unable to insert value ... (1014 byte value)

Largest values of 998...1012 and 2022...2037 bytes are affected.

Fix — Add the tag size to the maximum value size in resolveForKeywordDatabase.

Behavior change — With Symmetric PIR and a largest value of exactly 997 bytes, the default maxSerializedBucketSize goes from 1024 to 2048 bytes.

Testing — New regression test symmetricPirMaxSerializedBucketSize. swift test -c release passes.

PR #336 (Oct 4) — Fix accumulator overflow in modular matrix multiplication:

Summary — Fixes an accumulator overflow in Array2d.multiply(_:modulus:) and Array2d.multiply(transposing:modulus:offset:) that produces wrong results for large moduli.

Problem — Both functions sum products in T.DoubleWidth and reduce only once at the end, so the sum wraps past T.DoubleWidth.max. At the largest supported modulus, this happens after 16 products. In SimplePIR, SimplePirServer<UInt32> with a 28-bit ciphertext modulus returns incorrect entries at lattice dimension 2048.

Changes — Reduce the running sum after at most maxLazyProductAccumulationCount products, as the BFV inner product already does. Derive the count from the largest values in the two matrices, so inputs that cannot overflow keep a single reduction. Move the inner loop into a shared Array2d.innerProduct helper used by both functions.

Testing — Added Array2dTests.multiply, Array2dTests.maxLazyProductAccumulationCount and SimplePirTests.multiplyTransposing. The two multiply tests fail on main for 17 and 64 products and pass with this change. swift test -c release passes.

Performance — No slowdown measured when a single reduction suffices. 4% to 24% slower in the cases that were previously wrong.

Notes for reviewers — In PrecomputedQueries, one operand is the secret matrix, so the count depends on its largest value. Bounding by the modulus instead avoids that, but slows the UInt32 hint computation. Happy to switch.

PR #335 (Oct 4) — Clear stale seed from ciphertext-plaintext inner product result:

Problem — The BFV ciphertext-plaintext inner product builds its result from a copy of the first ciphertext and keeps that ciphertext's seed. If the first ciphertext is fresh, serializing the result uses the seeded format, so deserialization regenerates the second polynomial from the seed and the result decrypts incorrectly.

Fix — reduceToCiphertext now clears the result's seed. This covers all three ciphertext-plaintext variants: innerProduct, innerProductAsync and innerProduct(..., maxConcurrentTasks:).

Testing — schemeCiphertextPlaintextInnerProductTest now round-trips each inner product result through serialization and checks it still decrypts correctly. It fails without the fix. swift test --configuration release passes.

PR #334 (Oct 4) — Fix sharded index database overwriting its output files:

Problem — With "databaseType": "index" and more than one shard, PIRProcessDatabase accepts outputDatabase and outputPirParameters paths that do not contain SHARD_ID. Every shard is then written to the same path, so only the last shard written survives, and the tool exits with code 0.

The keyword path already rejects this configuration in ResolvedArguments.validate(). The index path never ran that check.

Reproduction — An index database with 8 rows and this config:

json { "inputDatabase": "index-db.txtpb", "outputDatabase": "database.bin", "outputPirParameters": "pir-parameters.txtpb", "rlweParameters": "n_4096_logq_27_28_28_logt_5", "databaseType": "index", "sharding": { "shardCount": 4 } }

• Before: 4 Saved shard to database.bin log lines, exit code 0, and the one remaining pir-parameters.txtpb has num_entries: 2.
• After: Error: 'outputPirParameters' must contain 'SHARD_ID', exit code 64, nothing written.

Fix — Add Arguments.validateForIndexDatabase(), which applies the same SHARD_ID rule as the keyword path. Call it at the start of processIndexDatabase, before the input database is read. Single-shard configurations, including the default, are unaffected.

Testing — New test indexDatabaseShardID in ProcessDatabaseTests. swift test --filter PIRProcessDatabaseTests passes.